Les lenteurs insidieuses dans Oracle… et comment les voir venir

Jean-Michel Alluguette – OP&S
30 août 2025
5 min de lecture

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

Les lenteurs Oracle les plus coûteuses ne commencent pas par une panne.

Elles s’installent progressivement :

une requête un peu plus lente chaque semaine,
un batch qui glisse de 45 min à 1h10,
une latence I/O qui dérive,
une charge qui augmente sans alerte “rouge”.

Et c’est précisément ce qui les rend dangereuses : au quotidien, ça passe.

Puis un jour, la fenêtre batch explose, les utilisateurs se plaignent, et l’analyse devient urgente.

La bonne nouvelle : pour détecter ces dérives, vous n’avez pas besoin d’organiser un benchmark sur plusieurs semaines.

Si vous collectez correctement et en continu les métriques Oracle, la baseline existe déjà — et les déviations deviennent visibles immédiatement.

C’est exactement l’intérêt d’OP&S : collecter à l’heure, conserver sur la durée, et rendre les dérives lisibles.

Pourquoi les lenteurs progressives échappent aux équipes

1) Les seuils classiques déclenchent trop tard

Les alertes “CPU > 90%” ou “disque < 10%” détectent l’urgence, pas la dérive.

Or une dérive commence souvent par +5%, +10%, +15%… ce qui ne déclenche rien.

2) Le temps réel masque les tendances

Quand vous regardez une base Oracle en temps réel, vous voyez surtout :

des pics,
des creux,
du bruit.

Une dérive insidieuse, elle, se voit surtout quand on compare :

“mardi 10h” avec “mardi 10h”,
“batch de nuit” sur les 10 dernières exécutions,
“clôture mensuelle” mois après mois.

3) “On n’a rien changé” est souvent faux

Même si l’application n’a pas changé, le système, lui, dérive :

volumétrie,
stats,
concurrence,
stockage,
saturation progressive,
patchs,
nouveaux flux…

Sans historique exploitable, vous ne pouvez pas prouver ce qui se passe.

Les causes les plus fréquentes de dérives lentes sur Oracle

Les lenteurs insidieuses ont rarement une cause unique. Les plus courantes :

Croissance volumétrique (tables, index, historiques)
Statistiques et plans d’exécution qui changent progressivement
Dérive I/O (latence, saturation, stockage moins performant qu’avant)
Contestation / concurrence qui augmente avec l’usage (locks, contention)
Paramètres qui ne matchent plus (TEMP/UNDO, redo, SGA/PGA…)
Changements infra/app sans mesure “avant / après”

Le point important : ces facteurs produisent rarement un incident immédiat.

Ils produisent une dégradation lente… jusqu’au point de rupture.

La vraie difficulté : “voir” la déviation sans faire un benchmark

Dans une entreprise, quand on dit “il faut une baseline”, beaucoup entendent :

“Il faut lancer une campagne de tests, mesurer pendant 3 semaines, benchmarker…”

En réalité, ce n’est pas nécessaire si vous avez un outil qui :

collecte régulièrement (par exemple à l’heure),
conserve l’historique,
et permet de comparer des périodes similaires.

Autrement dit : la baseline est construite automatiquement par la collecte continue.

Demander un PoC gratuit (1 mois)

Ce que change une collecte horaire conservée sur des années

Avec une collecte horaire historisée, vous pouvez répondre immédiatement à des questions de pilotage :

Est-ce que ce batch est plus lent aujourd’hui qu’il y a 1 mois ? 3 mois ? 1 an ?
Est-ce que la latence I/O dérive à charge comparable ?
Est-ce qu’un type de wait (I/O / Concurrency / Configuration) prend de plus en plus de place ?
Est-ce que la volumétrie croît de façon linéaire ou accélérée ?
Est-ce qu’une base “glisse” progressivement vers la zone rouge ?

C’est exactement ce qui permet d’identifier les lenteurs insidieuses :

pas un benchmark manuel, mais la comparaison de l’historique.

Comment OP&S rend ces dérives visibles (concrètement)

OP&S collecte les métriques Oracle à l’heure, conserve l’historique sur la durée, et permet de visualiser :

la tendance des métriques clés,
les déviations par rapport aux périodes comparables,
la signature des lenteurs (CPU, I/O, concurrency, configuration),
et les environnements qui se dégradent.

L’objectif est simple : passer de “ça ralentit” à :

“ça dérive depuis X semaines”,
“ça se manifeste surtout sur tels créneaux”,
“la cause ressemble à I/O / contention / configuration”,
“voici les environnements à traiter en priorité”.

Les 6 indicateurs qui révèlent le plus vite une dérive (sans se noyer)

Vous n’avez pas besoin de 50 KPIs. Vous avez besoin de quelques métriques stables dans le temps :

Charge globale / DB Time (et son évolution)
Répartition des waits (I/O / Concurrency / Configuration / Commit)
Latence I/O (et sa tendance)
Consommation CPU à charge comparable
Volumétrie (DATA / index / TEMP / UNDO) et croissance
Temps des traitements clés (batchs, flux ERP, traitements critiques)

Ces métriques, collectées régulièrement et historisées, suffisent à rendre visible une grande partie des dérives.

Check-list : détecter une dérive en quelques minutes (avec l’historique)

Le temps d’un traitement clé augmente-t-il sur plusieurs exécutions ?
La base montre-t-elle une hausse de waits à charge comparable ?
Un nouveau type de wait devient-il dominant (I/O, concurrency, configuration…) ?
La latence I/O dérive-t-elle au fil des semaines ?
La volumétrie augmente-t-elle plus vite que prévu ?
TEMP/UNDO/redo sont-ils proches des limites lors des pics ?
Observe-t-on des régressions après une action (patch, migration, paramètre) ?
Les plaintes utilisateurs correspondent-elles à des créneaux récurrents ?
Une base bascule-t-elle progressivement dans le top des bases “à risque” ?
Avez-vous une comparaison immédiate “ce mois-ci vs mois dernier” sur les mêmes créneaux ?

Si plusieurs réponses sont “oui”, vous êtes face à une dérive, pas à un incident ponctuel.

Les erreurs qui coûtent cher

Erreur #1 : tout gérer au seuil (et ignorer les tendances)

Les seuils détectent l’urgence.

Les tendances détectent la dérive avant l’urgence.

Erreur #2 : analyser uniquement après la crise

Quand la crise arrive, vous n’avez plus de marge.

Alors que corriger une dérive tôt est souvent simple (paramètre, index, purge, stockage, stats…).

Erreur #3 : ne pas conserver l’historique assez longtemps

Beaucoup de systèmes perdent le contexte après quelques jours/semaines.

Or les dérives s’étalent souvent sur des mois.

Conclusion

Les lenteurs insidieuses Oracle sont difficiles à détecter quand on ne regarde que le temps réel.

Mais avec une collecte régulière et un historique long, elles deviennent visibles :

vous observez la dérive,
vous la qualifiez (I/O, concurrency, configuration…),
vous priorisez les actions,
et vous évitez la crise.

C’est précisément l’intérêt d’OP&S : pas besoin de mettre en place un benchmark manuel, la baseline existe déjà grâce à la collecte continue et à l’historique.

Offre d’audit pour repérer les lenteurs avant qu’elles ne deviennent critiques

Pour vous aider à repérer les lenteurs insidieuses avant qu’elles ne deviennent critiques, nous proposons un audit Oracle gratuit d’un mois avec rapport détaillé.

Vous saurez exactement où intervenir pour maintenir des performances optimales… avant que les utilisateurs ne se plaignent.