JD Edwards : comment nous avons résolu un problème de concurrency Oracle sans Diagnostic Pack
- Jean-Michel Alluguette – OP&S
- 9 oct. 2025
- 5 min de lecture
Dernière mise à jour : 17 déc. 2025
Dans un environnement JD Edwards, les symptômes de performance sont souvent trompeurs.
Un utilisateur dit “JDE est lent”, un batch dure plus longtemps, et on pense immédiatement : CNC, réseau, application, charge serveur…
Sauf que, dans beaucoup de cas, la cause est côté Oracle : la base ne “tient” plus la concurrence (concurrency).
Autrement dit : des sessions se bloquent mutuellement. Ce n’est pas forcément une panne, c’est une friction interne qui fait exploser les temps de réponse.
Dans ce retour d’expérience, je raconte un cas réel : des lenteurs récurrentes sur JDE, un diagnostic qui pointe vers un problème de verrous / contention Oracle, et une résolution sans Diagnostic Pack.
Contexte : lenteurs régulières et ressenti utilisateur
Le client exploite JD Edwards sur Oracle.
Les utilisateurs constatent :
des lenteurs qui apparaissent à certaines périodes,
une dégradation qui semble “aléatoire”,
parfois des écrans qui “moulinent” sans erreur explicite.
Côté exploitation, le problème n’est pas évident :
la base ne tombe pas,
la charge CPU peut sembler “acceptable”,
et les alertes classiques ne déclenchent rien de clair.
C’est typiquement le genre d’incident où on perd du temps parce qu’on n’a pas de preuve immédiate.
Ce qu’on cherche à déterminer en premier
Avant d’aller trop loin, il faut répondre à 3 questions simples :
Est-ce que le goulot est Oracle ou ailleurs ?
Si c’est Oracle, est-ce un problème de CPU / I/O ou de concurrence / verrous ?
Si c’est de la concurrence, qui bloque qui et pourquoi ?
OP&S aide justement à dérouler cette logique rapidement.
Étape 1 — Visualiser la charge globale : reconnaître un profil “concurrency”
Première étape : regarder la charge Oracle sur une période représentative (plusieurs jours, pas 30 minutes).
Dans OP&S, on observe :
des pics de charge récurrents,
un DB Time qui augmente,
mais sans augmentation proportionnelle de CPU ou d’I/O.
Ce profil est souvent le signe d’un problème de concurrency :
la base passe du temps à attendre (locks, latches, contention), plutôt qu’à travailler (CPU) ou à lire/écrire (I/O).
L’intérêt ici : on ne part pas dans le tuning “au hasard”, on sait déjà sur quel axe creuser.
Étape 2 — Descendre dans les temps d’attente : la signature “library cache lock”
Deuxième étape : analyser les wait events (les temps d’attente Oracle).
Dans ce cas, un événement ressort massivement :
library cache lock
Sans rentrer dans un jargon Oracle inutile, retiens ceci :
le “library cache” est une zone où Oracle gère des objets partagés (SQL, plans, objets compilés…).
Quand trop de sessions se battent sur les mêmes objets (ou qu’une opération de maintenance perturbe le mécanisme), cela peut provoquer des blocages internes.
Résultat côté utilisateur : lenteurs, blocages, et surtout une impression d’instabilité.
Ce signal est puissant :
on n’est pas sur “un SQL lent” classique, mais sur un problème structurel de concurrence.
Étape 3 — Identifier les sessions et le SQL responsable
Une fois le type d’attente identifié, l’étape suivante est simple :
qui génère ces verrous ? et sur quoi ?
OP&S permet de remonter :
les sessions les plus actives pendant les périodes de lenteur,
les SQL_ID impliqués,
la fréquence des blocages,
et le contexte (horaire, batch, processus JDE, etc.).
C’est ici que beaucoup d’équipes se perdent sans outil :
elles voient “library cache lock”, mais n’arrivent pas à relier ça à un processus concret.
Dans ce cas, l’analyse met en évidence un lien avec des opérations liées aux statistiques (collecte / rafraîchissement), qui créaient une concurrence anormale.
Étape 4 — Le point déterminant : un mode de collecte de statistiques problématique
La collecte de statistiques Oracle est indispensable… mais elle peut être dangereuse si elle est :
mal configurée,
déclenchée au mauvais moment,
ou faite avec une méthode qui provoque une concurrence élevée.
Dans ce cas, le diagnostic a conduit à identifier un problème connu / documenté côté Oracle :
le mode de collecte des statistiques déclenchait une contention, et cela se traduisait par des “library cache lock” en masse.
Le piège : ce problème peut se produire même si “tout semble normal” dans la journée.
Il suffit d’une fenêtre de batch, d’un job de stats, et vous retrouvez des lenteurs côté JDE.
Étape 5 — Correction : ajuster la stratégie de statistiques (sans casser l’ERP)
La correction a consisté à :
revoir la configuration des jobs de stats,
ajuster le mode de collecte,
et synchroniser ces actions avec la réalité des traitements JDE (batchs, fenêtres nocturnes, périodes sensibles).
Objectif : conserver des stats fiables (donc de bons plans d’exécution), sans provoquer de contention.
Étape 6 — Validation : mesurer la disparition de la contention
Après correction, OP&S permet de valider de manière factuelle :
chute des occurrences de library cache lock,
baisse des pics de charge liés aux temps d’attente,
amélioration visible des temps de réponse et des batchs,
diminution des plaintes utilisateurs.
C’est un point clé : en performance, “on pense que c’est mieux” ne suffit pas. Il faut mesurer.
Check-list : comment diagnostiquer vite un problème de concurrency sur Oracle (spécial JDE)
1) Confirmer que le problème vient de la base
DB Time augmente-t-il sans hausse équivalente CPU / I/O ?
Le problème apparaît-il sur des créneaux récurrents (batch, horaires précis) ?
2) Identifier la classe de wait dominante
Concurrency / Locks ?
Configuration ?
I/O ?
CPU ?
3) Isoler l’attente principale
Exemple : library cache lock
Regarder fréquence, périodes, corrélation avec des jobs.
4) Remonter aux sessions / SQL_ID
Quelles sessions consomment et attendent le plus ?
Quels SQL_ID sont corrélés aux pics ?
Est-ce lié à un batch JDE ou une maintenance Oracle ?
5) Vérifier les opérations “invisibles” mais critiques
Collecte de statistiques
Recompilations
Maintenance ou jobs internes
Changements récents (patch, paramètre, migration)
Pourquoi ces incidents sont fréquents sur JDE
JDE a des caractéristiques qui amplifient les phénomènes de concurrence :
batchs lourds concentrés sur des fenêtres de temps,
accès concurrents sur certains objets,
périodes de forte activité (clôtures, traitements mensuels, etc.),
opérations de maintenance souvent planifiées “à côté” des batchs (stats, maintenance, etc.).
Ce n’est pas “la faute de JDE” ou “la faute d’Oracle” : c’est une réalité d’exploitation, et il faut des outils pour l’objectiver.
Conclusion
Un problème de concurrency Oracle peut transformer un environnement JD Edwards stable en environnement “lent” sans panne franche.
Dans ce REX, l’analyse des temps d’attente a mis en évidence un phénomène massif de library cache lock, lié à une stratégie de statistiques inadaptée.
Une fois la correction appliquée, la disparition des verrous et la stabilisation des performances ont été mesurées clairement.
Le point important : tout cela a été fait sans Diagnostic Pack, avec une approche structurée et des métriques factuelles.
Vous gérez un environnement JDE avec des lenteurs inexpliquées ?
Un PoC d’OP&S permet :
d’analyser vos événements d’attente réels,
d’identifier les problèmes de concurrency,
de disposer de preuves factuelles pour corriger durablement.
À propos de l’auteur
Jean-Michel Alluguette est le fondateur d’OP&S, un logiciel dédié aux environnements Oracle et ERP (JD Edwards / E-Business Suite) pour piloter performance, coûts (FinOps) et sécurité/licences.
Vous souhaitez une analyse factuelle de vos bases Oracle ? → Demander un PoC gratuit de 1 mois.
Commentaires