JD Edwards sur AWS : comment une recréation d’instance Oracle a dégradé les performances (et comment OP&S l’a détecté)

Jean-Michel Alluguette – OP&S
30 sept. 2025
5 min de lecture

Dernière mise à jour : 17 déc. 2025

Migrer, reconstruire ou “recréer” une instance Oracle sur AWS pour un environnement JD Edwards, c’est une opération assez fréquente : besoin de place, nettoyage, changement de type d’instance, refonte du stockage, standardisation…

Le problème, c’est que derrière un terme qui paraît simple (“on recrée l’instance”), se cache souvent un risque sous-estimé : une partie des paramètres Oracle et des choix d’architecture revient à un état par défaut.

Et ces “petites différences” peuvent suffire à transformer un environnement stable en un environnement qui rame — sans que personne ne comprenne immédiatement pourquoi.

Dans ce retour d’expérience, je vous raconte un cas réel : une reconstruction sur AWS a entraîné une dégradation de performance sur JD Edwards, et comment OP&S a permis d’identifier très rapidement l’origine du problème.

Le contexte : reconstruction AWS pour regagner de l’espace

Le client exploite un ERP JD Edwards sur une base Oracle hébergée sur AWS.

Suite à un besoin de regain d’espace et de nettoyage, l’équipe décide de recréer l’instance Oracle (nouvelle instance, rechargement des données, remise à niveau technique).

Sur le papier, l’opération est maîtrisée : même version Oracle, mêmes données, mêmes flux applicatifs.

Sauf qu’en pratique, une reconstruction est rarement parfaitement “équivalente” :

le stockage peut changer (EBS, paramètres IOPS, throughput),
les tailles et la configuration de certains objets peuvent être différentes,
des paramètres Oracle reviennent à des valeurs par défaut,
et des éléments invisibles au premier coup d’œil (redo logs, TEMP/UNDO, stats, etc.) peuvent dériver.

Symptômes côté métier : “JD Edwards est lent” (mais sans preuve)

Dans les jours qui suivent :

lenteurs ressenties par les utilisateurs,
traitements qui durent plus longtemps,
et une perception globale de dégradation.

Côté infra, rien ne semble exploser : pas d’incident majeur, pas de panne.

C’est typiquement le genre de situation où on perd énormément de temps, parce qu’on alterne entre hypothèses :

“AWS a changé quelque chose”,
“c’est JDE”,
“c’est la base”,
“c’est le stockage”,
“c’est la volumétrie”.

Dans ce cas, l’objectif a été d’arrêter les suppositions et de repartir d’une base factuelle.

Ce que montre OP&S : avant / après, noir sur blanc

Grâce à OP&S, la comparaison avant / après est immédiate.

Volumétrie
- Les données (DATA) sont correctes,
- mais les espaces TEMP / UNDO et redo logs apparaissent mal dimensionnés.
Charges DB
- De nouveaux temps d’attente Oracle de type “Configuration” émergent,
- ce qui pointe vers des paramètres inadaptés.
Redo logs
- Les indicateurs montrent des événements “log file switch (checkpoint incomplete)” en hausse,
- redologs trop petits → jusqu’à 45 000 secondes d’attente par jour.
Autres signaux
- Événements “buffer busy wait” et autres symptômes d’un stockage mal adapté ou de paramètres non optimisés.

Étape 1 — Comparer avant / après (sans débat)

Le premier réflexe à avoir dans ce type d’incident : comparer l’environnement avant et après.

OP&S permet de comparer :

volumétrie (DATA / TEMP / UNDO),
charge de la base,
temps d’attente (wait events) et leur répartition,
indicateurs d’écriture (redo logs),
signaux de contention et d’I/O.

Le point crucial : sans historique ou sans comparaison, on perd un temps fou.

Avec une vue “avant / après”, vous voyez immédiatement si l’environnement “se comporte” différemment.

Étape 2 — Vérifier la volumétrie et le dimensionnement (DATA, TEMP, UNDO)

Dans ce cas précis, l’analyse volumétrique met déjà en évidence un signal :

la volumétrie DATA est cohérente,
mais TEMP / UNDO apparaissent différemment dimensionnés par rapport à l’environnement précédent,
et certains choix de sizing ne correspondent plus au profil réel de charge.

Evolution de la volumétrie TEMP, UNDO et REDOLOGS. Besoin de resize post migration.

Or sur JDE (batchs, traitements, grosses requêtes), TEMP et UNDO mal dimensionnés peuvent provoquer :

des surcoûts I/O,
des ralentissements en cas de pics,
et des phénomènes de saturation difficiles à expliquer côté ERP.

Étape 3 — Analyser les temps d’attente : quand “Configuration” apparaît

En parallèle, l’analyse des “wait events” met en évidence l’apparition (ou l’augmentation) d’événements classés côté Oracle comme liés à la configuration.

C’est un signal important : ce n’est pas une requête isolée ou une charge applicative “normale”.

C’est l’infrastructure / le paramétrage de la base qui ne colle plus au besoin réel.

Demander un PoC gratuit (1 mois)

Étape 4 — Le point clé du REX : redo logs trop petits, et explosion des wait events

Dans ce cas, le diagnostic s’est accéléré grâce à une observation très nette : les indicateurs liés aux redo logs partaient dans le mauvais sens.

Quand les redo logs sont trop petits, la base “switch” trop souvent et peut finir par générer des waits du type :

log file switch (checkpoint incomplete)
ou des temps d’attente liés aux checkpoints / écritures.

Et ça a une conséquence directe :

la base passe du temps à gérer ses écritures au lieu de servir les requêtes,
et les traitements JDE ralentissent, parfois de manière intermittente (donc difficile à prouver sans mesures).

Dans notre cas, un ordre de grandeur très parlant : jusqu’à ~45 000 secondes d’attente par jour sur ces phénomènes.

C’est énorme. Et ça suffit à expliquer à lui seul une grosse partie de la dégradation ressentie.

Temps d'attentes "log file switch (checkpoint incomplete) détectés

Étape 5 — Vérifier les autres signaux (buffer busy wait, stockage, etc.)

Une reconstruction sur AWS change souvent plusieurs paramètres à la fois.

Dans le même diagnostic, OP&S permet aussi de surveiller :

buffer busy waits (contention sur des blocs chauds),
indicateurs d’I/O (latence, saturation),
consommation CPU,
comportement mémoire.

L’intérêt : éviter de corriger un point (redo logs) tout en passant à côté d’un deuxième facteur (stockage ou contention) qui continuerait à dégrader l’ERP.

Étape 6 — Correction et validation : on mesure le retour à la normale

Une fois les redologs redimensionnés (et les paramètres associés revus), la validation doit être factuelle :

baisse des waits liés aux log switches / checkpoints,
amélioration des courbes de charge,
réduction du temps total passé en attente,
amélioration visible des temps de traitement.

C’est exactement l’intérêt d’OP&S dans ce type de contexte : vous ne “pensez pas” que c’est mieux, vous le voyez sur les métriques.

Check-list : quoi vérifier après une recréation Oracle (spécial JDE sur AWS)

Paramètres Oracle & fichiers

Taille et nombre des redo logs (et fréquence de switch)
Dimensionnement TEMP et UNDO
Paramètres de base liés à la mémoire (SGA/PGA) et comportement en pic
Statistiques / mode de collecte et jobs associés
Paramètres de checkpoint et d’écriture

Stockage AWS (souvent sous-estimé)

Type de volume (EBS), IOPS et throughput cohérents avec la charge
Latence I/O réelle en période de batch
Répartition des fichiers (DATA, TEMP, UNDO, REDO) et contention potentielle

Exploitation / runbook

Comparaison avant / après sur une période représentative
Monitoring des waits par classe (I/O, Concurrency, Configuration)
Validation sur des traitements JDE critiques (batchs de nuit, R42800, etc.)

Ce que ce REX montre (et que beaucoup d’équipes sous-estiment)

Recréer une instance Oracle n’est pas neutre : Même si les données et la version Oracle sont identiques, l’environnement “technique” peut changer.
Les redo logs sont un piège classique : C’est souvent “petit” dans la check-list, mais l’impact peut être énorme sur la production.
Sans historique, vous perdez un temps fou : Un bon outil doit permettre de comparer et d’isoler les changements objectivement.

Conclusion

Ce cas réel illustre une réalité simple : dans un projet AWS, les performances ne se jouent pas uniquement sur la puissance de l’instance.

Elles se jouent dans les détails : redo logs, TEMP/UNDO, stockage, paramètres Oracle.

Avec OP&S, vous pouvez :

objectiver avant / après,
détecter rapidement les waits anormaux,
corriger et valider les gains,
sans dépendre d’options Oracle coûteuses.

Vous avez migré JDE sur AWS (ou vous y pensez) ?

Un PoC OP&S de 1 mois permet :

de capturer l’état actuel de vos bases Oracle JDE,
d’identifier les dérives de configuration ou de performance,
et de préparer sereinement vos futures évolutions.