Interpréter le contenu du Buffer Cache Analyzer

Trucs et Astuces

✓ d.side temps réel
✓ d.side Replay

Objectifs des Analyzers d.side

Les Analyzers, comme l’écran principal de d.side, ont pour fonction de détecter si l’instance Oracle surveillée est pénalisée par un problème de performances. Et le cas échéant, de mettre sur la piste d’une résolution en pointant l’origine du ralentissement ou du blocage.

Pour cela on cherche donc à repérer un éventuel excès de consommation ou d’attente.

Et une fois les symptômes détectés, l’Analyzer nous permet de comprendre et d’expliquer ce qui en est la cause, afin de travailler sur les éléments responsables de cette situation.

Objectifs du Buffer Cache Analyzer

Dans le cadre du Buffer Cache Analyzer, un excès est lié à une sollicitation anormale du buffer cache Oracle.

Cela peut par exemple se traduire par :

– Un buffer cache Oracle trop sollicité ou mal utilisé
– Des sessions en attente sur des contentions au niveau du buffer cache
– Des requêtes qui consomment beaucoup de CPU
– Des requêtes qui traitent beaucoup de blocs
– Des objets ou des segments qui sont trop souvent touchés
– Une consommation de CPU importante au niveau de la machine (host)
– Des contentions de type « latch free » sur le buffer cache Oracle

Le Buffer Cache Analyzer va permettre d’observer comment se comporte le buffer cache Oracle, afin de détecter des requêtes, des sessions ou des objets provoquant une consommation importante de ressources.

Comment utiliser le Buffer Cache Analyzer

Le Buffer Cache Analyzer contient trois zones distinctes :

Oracle Buffer Cache Statistics

Cette section présente le paramétrage et les statistiques relatives à la configuration et l’utilisation du buffer cache Oracle : nom des pools (DEFAULT, RECYCLE, KEEP), taille réelle, taille du bloc (4K, 8K, 32K…) ainsi que le buffer cache hit ratio moyen (depuis le startup de l’instance) et temps réel.

Current Contentions

Si des sessions sont en attente sur des contentions liées au buffer cache Oracle, alors cette zone les liste, en précisant qui attend sur quoi, c’est-à-dire quelle session est bloquée alors qu’elle exécute quelle requête SQL, sur quel événement d’attente Oracle.

Selon l’attente observée (“buffer busy wait”, par exemple) le détail du bloc en contention est également affiché pour permettre de détecter si la contention correspond à un bloc de données ou d’index particulier ou si les attentes sont réparties sur plus d’espace.

Most Read Segments

Elément unique proposé par d.side, cette partie ne montre pas le volume qu’occupe chaque objet dans le buffer cache Oracle, mais son niveau d’utilisation. On voit ainsi directement si une petite table est très sollicitée, provoquant potentiellement des attentes, alors qu’une grande table volumineuse qui ne pose pas de problème de performances ne sera pas affichée ici.

C’est un outil très efficace pour déterminer par exemple si un index a été mal choisi ou est mal exploité par Oracle dans un plan d’exécution.
Les informations affichées ici incluent l’identification de l’objet avec son nom, son type (INDEX, TABLE…), à quel schéma il appartient, et s’il s’agit d’une partition (Subobject Name), ainsi que le nombre de fois que cet objet a été touché sur l’intervalle (un intervalle, par défaut, correspond à 5 secondes en temps réel ou une minute en Replay. Il s’agit du temps écoulé entre deux rafraîchissements des informations par d.side ou entre deux prises de snapshots).

Associées au nombre de fois que l’objet a été touché, les barres de progression indiquent en proportion du total si cette valeur est importante. Par exemple, dans le cas suivant, on identifie facilement le fait que l’activité Oracle observée concerne quasi exclusivement la table BIEDI dont les blocs ont été utilisés plus d’un million de fois sur l’intervalle, ce qui représente environ 95% de tout le trafic en buffer cache Oracle.

Pour plus de fluidité, seuls les 10 segments les plus sollicités dans le buffer cache Oracle sont affichés dans cette liste, l’objectif étant bien de voir les plus importantes valeurs, représentant les objets qui peuvent poser des problèmes, pas de tout lister.

Autres informations

On peut obtenir encore plus de détails à partir de ces zones.

– Double-clic sur une ligne en Current Contention : ouvre une fenêtre Session Info de la session en attente

– Clic droit sur une ligne en Current Contention : permet d’ouvrir une fenêtre SQL Info de la requête

– Clic droit sur une session en attente : selon l’attente, précise dans la zone Block Info l’objet sur lequel porte la contention

– Double-clic sur une ligne de la zone Segments : ouvre une fenêtre Segment Statistics

Comment ouvrir le Buffer Cache Analyzer

Le Buffer Cache Analyzer est accessible depuis le menu Analyzers de d.side :

On peut également ouvrir le Buffer Cache Analyzer en double cliquant dans l’écran principal sur un événement d’attente qui correspond à une attente liée au comportement du buffer cache Oracle.
Exemple :

Par ailleurs, cliquer sur la statistique « logical reads » de la zone « Main Statistics (per second) » de l’écran principal permet aussi d’entrer dans le Buffer Cache Analyzer.

Exemples d’utilisation

Cas 1

Les informations remontées par le Buffer Cache Analyzer nous indiquent qu’il n’y a aucune contention et que les objets sont utilisés de manière homogène en mémoire :

Le buffer cache Oracle ne semble pas poser de problème ici, et aucune session ou requête SQL n’est pointée comme étant un élément à optimiser.

Cas 2

En revanche ici on observe bien des contentions, liées à deux requêtes SQL différentes mais dont la structure est similaire. Et la seule table MIFI4 est touchée plus de 48 millions de fois sur l’intervalle, ce qui représente plus de 80% de toute l’activité et quasiment 6 fois plus que l’objet suivant dans la liste.

Ces éléments ont amené à optimiser les deux requêtes pour lesquelles un mauvais plan d’exécution était choisi par Oracle du fait d’un problème sur les statistiques destinées à l’optimiseur.

Conclusion

Le Buffer Cache Analyzer de d.side permet d’observer avec précision et rapidité tout ce qu’il est important de savoir sur le fonctionnement du buffer cache Oracle. On peut ainsi détecter et déterminer la cause de ralentissements ou de contentions sur cette zone mémoire.

Les responsables de ces problèmes de performances peuvent être une session, une requête SQL, un buffer cache trop petit, etc.

Très souvent des problèmes liés au buffer cache sont accompagnés d’autres symptômes visibles sur l’écran principal de d.side : consommation de CPU par Oracle ou par la machine, requêtes consommant beaucoup de CPU ou de blocs, contentions, attentes de type « latch free ».

Dans la plupart des cas, optimiser les requêtes SQL identifiées sera la manière la plus efficace de résoudre les problèmes ou attentes sur le buffer cache.