La lecture d'un rapport AWR (Automatic Workload Repository)

La période de rapport :
- OLTP en journée / batch la nuit
- Spécifique à une action logicielle
- Tests de charge représentatifs

La participation d’Oracle sur la CPU utilisée :
- DB time vs elapsed time => Dbtime / elapsed time = sessions actives moyennes

Instance Efficiency Percentages

- Comprendre les ratios en fonction de l’activité :
- En OLTP : Expliquer les ratios < 98 ; s’attarder sur les ratios < 95

Buffer hit ratio

C’est le ratio entre les requêtes satisfaites à partir du cache et les requêtes nécessitant un accès disque. Ce ratio sera très déterminant pour des applications web ou visualisations « temps réelles ».

S’il est trop bas sur des traitements OLTP, il faut s’attarder à sur le db_cache_size

Buffer Nowait ratio

C’est le ratio de disponibilité d’un buffer (100% signifie qu’aucun lock de buffer n’a été rencontré) ; si ce ratio est faible (< 95%), il faut se rendre à la section Buffer Wait Statistics du présent AWR pour déterminer quels types de buffer provoquent des contentions (appelés Hot blocks).

Library Hit ratio

C’est le ratio entre les requêtes envoyées au serveur et les requêtes dont le plan d’exécution est en cache.

Ce ratio est primordial pour les traitement OLTP. S’il est trop bas, il faudra agir soit sur la taille de la library cache soit revoir les accès aux données (cursor sharing), éviter la construction des requêtes dynamiques tous azimuts.

Execute to Parse %

Ce ratio est un peu plus compliqué à calculer : sa formule est : 100 * (1 – nb Parses/nb Executions) ; il indique donc le pourcentage de requête ne nécessitant pas d’être parsées ; c'est-à-dire dont le plan d’exécution précédemment calculé est disponible et utilisé.

Si la valeur de ce ratio est basse, il faut alors regarder le ratio soft parse ; si celui-ci révèle un taux faible également pour un système OLTP, il s’agit de revoir l’accès aux données (cursor sharing, requêtes dynamiques, ...) car Oracle doit recalculer le plan d’exécution pour une grande partie des requêtes.



Top 5 wait events - Les attentes les plus courantes

  • wait class
  • %DB time

DB CPU

DB CPU est généralement indicateur de bonnes performances ; en effet, les temps de réponses dépendent directement du CPU.
Cependant, il faut nuancer cette affirmation dans le cas où l’applicatif est mal conçue ; par exemple en faisant de multiple accès et en utilisant des fonctions complexes qui pourraient être factorisées :

select label from matable where decode(to_date(monchampdate, ‘YYYY-MM-DD’), sysdate, ‘aujourd hui’, to_date(monchampdate, ‘YYYY-MM-DD’), sysdate-1, ‘hier’, to_date(monchampdate, ‘YYYY-MM-DD’), sysdate+1, ‘demain’) = ‘demain’ ;
devient

select label from matable where trunc(monchampdate) = trunc(sysdate)+1;

db file sequential read

C’est une des attentes que l’on retrouve très régulièrement dans le TOP 5 ; hormis une base de données dont la taille totale des index peut être en RAM ou un stockage dédié sur SSD, si ce n’est pas le cas, c’est qu’il y a de gros problèmes sur les attentes du TOP 5 (notamment pas d’index de créés). Il s’agit d’attentes de bloc de données lus dans les index.

db file scattered read

Il s’agit d’attentes due à la lecture de blocs de données multiple (généralement full table scan) cette attente est à considérer en même temps que la précédente.

hard parse time elapsed

En mode OLTP, cette attente rejoins généralement le problème décrit au § Execute to Parse %.

log file parallel write & log file sync

Généralement constaté sur des systèmes fortement mis à jour, ces attentes correspondent à l’écriture dans les redo log (uniquement en cas d’insert/update)

buffer busy waits

rejoint l’indicateur Buffer Nowait ratio : le système est fortement multi-process et certains blocs (et les données associées) sont fréquemment utilisés ; il faut dans ce cas améliorer les accès disques à ces blocs (indexer, mettre sur des disques plus performants, ALTER matable MINIMIZE RECORDS_PER_BLOCK, améliorer PCTUSED et PCTFREE, utiliser ASSM) ; allez voir à la section Segments by Physical Reads pour voir les segments potentiellement en cause.

Wait Event Histogram

Cette partie permet de savoir si les attentes relevées précédemment sont représentatives.
En effet, une moyenne très élevés pour une attente est un bon indicateur, cependant la distribution des valeurs est plus intéressant encore : si par exemple on relève une moyenne forte sur l’attente SQL*Net message to client mais qu’en réalité 98% des attentes sont inférieures à 1ms et 2% supérieures à 1s, il s’agit probablement d’un problème avec un client en particulier qui a un problème réseau.

La liste des requêtes selon différents critères

Enfin les parties listant les requêtes SQL suivant la CPU, le temps de réponse, le nombre d’IO, ... permettent d’identifier les requêtes problématiques.
Parmi les choses à regarder :
  • Une requête est exécutée très souvent : 10000 fois alors qu’il n’y a qu’un seul client qui a fait 3 clics dans l’application => symptôme d’une requête dans une boucle => Vérifier l’applicatif
  • Une requête contient un très grand nombre de variables (notamment dans un IN) => vérifier côté applicatif si ces paramètres ne sont pas issus du résultat d’une première requête, si tel est le cas, préférer une jointure)
  • Une requête n’est exécutée qu’une seule fois et est très longue => batch ou observateur (voir SQL Module)
  • Certaines requêtes sont consommatrices de lecture physique ou en attente IO => Vérifier les index
  • Une requête sans paramètre est exécutée très souvent => vérifier s’il ne s’agit pas de données de configuration, selon le cas, il peut être intéressant de les mettre en cache du côté applicatif
  • Requête INSERT exécutée très souvent => en cas d’insert de mass, il est parfois plus intéressant de supprimer les index le temps de l’opération pour le recréer juste après + vérifier s’il est pas possible d’écrire sous forme de d’insert multiple
  • Un job dbms_stats très long => il s’agit de la mise à jour des statistiques ; sur d’ancienne version (jusque 9i), vérifier si le calcul complet et la fréquence sont pertinents ; activer le monitoring de table




Vous n'avez pas trouver réponse à votre question ? Préciser votre recherche :

Catégories