Lorsqu'une base de données Oracle ralentit, le premier endroit où l'administrateur de bases de données doit se rendre est la base de données Oracle. Rapport de l'AWR - un aperçu détaillé de ce qui se passe à l'intérieur du système.
Il révèle où le temps est passé, quelles requêtes consomment des ressources et si la base de données est en bonne santé ou en difficulté.
Dans cet article, nous allons passer en revue les principales sections à vérifier afin que vous puissiez rapidement savoir si votre base de données est performante - et où concentrer vos efforts de réglage.
Voici l'ordre que je suis (et que suivent la plupart des administrateurs de bases de données seniors) lors de l'analyse d'un rapport AWR :
🔎 Analyse des RTA : Liste de contrôle étape par étape
1. Résumé du rapport (section supérieure)
Cela vous donne une aperçu rapide de la santé de la base de données.
- Temps de DB vs temps écoulé
- Indique le temps total consacré à l'activité de la base de données.
- 🔍 Si Temps DB ≈ Temps écoulé × #CPU coresLa charge de la DB est lourde.
- Règle de base :
- ✅ En bonne santé : Le temps de DB par seconde est similaire au nombre de CPU (par exemple, ~8 sec/s pour 8 CPU).
- ❌ Mauvais : Une valeur → beaucoup plus élevée indique des goulets d'étranglement.
- Moyenne des sessions actives (SMA)
- Temps DB / Temps écoulé
- ✅ En bonne santé : AAS ≤ nombre de cœurs de l'unité centrale.
- ❌ Mauvais : AAS > CPUs → le système est lié au CPU ou en attente de quelque chose.
- %DB CPU
- Pourcentage du temps de la base de données consacré à l'unité centrale.
- ✅ 60-90% signifie que la plupart du temps est consacré à des tâches utiles.
- ❌ Trop faible → la plupart des temps d'attente (IO, locks, latches, etc.).
2. ⚙️ Profil de charge
Cela vous indique à quel point votre DB est "occupé".
- Appels à la base de données / Transactions / Exécutions par seconde - Donne une idée de la charge de travail.
- Taille des redondances par seconde - Un nombre élevé de rétablissements = un nombre élevé de DML.
- Lectures logiques par seconde - Reflète l'activité du cache tampon.
- Lectures physiques par seconde - Des valeurs élevées peuvent signifier une mauvaise mise en cache ou des analyses complètes.
- Parses par seconde - Trop de parses = mauvais partage du curseur (recherchez un % élevé de parses durs).
✅ Signes de santé :
- Faible taux d'analyse syntaxique (<5%)
- Lectures logiques >> lectures physiques
- Parses par exec < 0.1 (ce qui signifie que la plupart des instructions sont réutilisées)
3. 🔥 Les 5 principaux événements temporels au premier plan
Il s'agit de le cœur de l'analyse AWR.
- Il montre où vous passez le plus clair de votre temps en DB.
- Recherchez les événements les plus attendus et vérifiez leur nature :
| Type d'événement | Signification | Ce qu'il faut penser |
|---|---|---|
Temps CPU | Un bon signe si l'on est en haut de l'échelle | La base de données est limitée par le CPU (vérifier AAS & CPU) |
lecture séquentielle d'un fichier de base de données | E/S en un seul bloc (recherche d'index) | OK si faible, mais élevé → lenteur des E/S ou accès excessif à l'index |
fichier de base de données en lecture dispersée | Balayage complet des tables | Index manquants éventuels |
synchronisation des fichiers journaux | L'engagement attend | Commencement trop fréquent ou lenteur de l'E/S de rétablissement |
enq : TX - contention du verrou de ligne | Contrainte de verrouillage | Problèmes de concurrence des applications |
latch : chaînes de tampons de cache | Contestation des blocs chauds | Optimisation du cache ou des requêtes |
buffer busy waits | Lutte pour les blocs | Problèmes de stockage ou d'accès aux données |
✅ En bonne santé :
- Temps d'utilisation de l'unité centrale au sommet ou près du sommet
- Les événements d'attente sont faibles en temps total (<20% temps total DB)
❌ Mauvais :
- Les attentes non-CPU dominent
- Un événement d'attente utilise >30-40% DB time → rechercher la cause première.
4. Pourcentages d'efficacité des instances
Cette section est souvent mal comprise, mais quelques mesures clés sont utiles :
- Touche de mémoire tampon % : Devrait être > 90%
- Bibliothèque % : Devrait être > 95%
- Soft Parse % : > 95% (si faible → vérifier le pool partagé ou le partage du curseur)
- Poussoir de verrouillage % : > 99%
Il s'agit de lignes directrices générales - de mauvais chiffres signifient une utilisation inefficace de la mémoire ou des problèmes de réutilisation de SQL.
5. 🔍 Principales instructions SQL
Vérifier le Top SQL by :
- Temps écoulé
- Temps CPU
- Buffer obtient
- Lecture physique
- Exécutions
✅ Sain :
- Aucun code SQL ne domine >30-40% du temps de la base de données.
❌ Problème :
- Une ou deux instructions SQL consomment le plus de ressources → c'est là qu'il faut d'abord régler les problèmes.
6. 🧰 Statistiques d'E/S et de fichiers
Vérifier Tablespace IO, Fichier IOet Segments par lecture physique:
- Recherchez les déséquilibres : un fichier de données ou un espace de tables effectuant 90% d'entrées-sorties → point chaud possible.
- Temps de lecture élevés (ms par lecture > 10 ms) → le sous-système IO est lent.
7. 🧵 Répartition des classes d'attente
Cela permet d'avoir une vue d'ensemble de où va le temps:
- CPU + E/S utilisateur : Généralement OK (charge de travail normale)
- Concurrence, engagement, configuration : Ajustement éventuel nécessaire
- E/S système ou réseau : Problèmes éventuels d'infrastructure
✅ Sain :
- La plupart du temps passé dans le CPU ou dans les E/S utilisateur.
❌ Mauvais :
- Pourcentage élevé dans les classes d'attente Concurrency, Commit ou Configuration.
8. 📈 Statistiques du système d'exploitation
Vérifier l'utilisation de l'unité centrale et la file d'attente :
- %User + %Sys CPU < 90% → CPU OK
- Si File d'attente > #CPUs → Saturation de l'unité centrale
Vérifiez également l'utilisation de la mémoire et de l'espace de pagination.
Liste de contrôle rapide de la santé (raccourci pour les administrateurs de bases de données)
| Vérifier | Bon signe | Mauvais signe |
|---|---|---|
| DB Temps / sec | ≈ Cœurs de l'unité centrale | >> Cœurs de l'unité centrale |
| AAS | ≤ Cœurs de l'unité centrale | >> Cœurs de l'unité centrale |
| Temps d'utilisation de l'unité centrale Événement le plus important | Oui | Non |
| Taux de réussite de la mémoire tampon | > 90% | < 85% |
| Taux d'analyse souple | > 95% | < 80% |
| Top SQL | Équilibré | 1-2 dominante SQL |
| Temps de latence de la lecture IO | < 10 ms | > 20 ms |
| Classes d'attente | Principalement CPU/User I/O | Concurrence, Commit, Config high |
| Parse dur % | < 5% | > 10% |
✅ En résumé :
Une base de données est bien faire si :
- Le temps de DB et l'AAS sont alignés sur la capacité de l'unité centrale.
- L'unité centrale est la principale "attente".
- Aucun événement SQL ou d'attente ne domine.
- Les taux de réussite sont élevés et les taux d'analyse sont faibles.
- La latence et l'encombrement des entrées-sorties sont minimes.