Historique du Load et de l'AAS

Détails: Catégorie : Tuning et Performance; Publié le vendredi 2 février 2018 20:18; Écrit par Administrator; Affichages : 11926

Quand on veut voir l’évolution dans le temps du load d’une base de données ou du AAS (Active Average Session), il faut requêter dba_hist_active_sess_history, à condition d’avoir une licence Diagnostic Pack. La vue contient autant d’historique que la période de rétention des snaphots AWR, (14 jours par défaut). Le résultat des requêtes n’est pas évident à formater pour avoir une vision synthétique et rapidement analysable.

En cherchant avec mon ami google, une requête permettant d’avoir une bonne vision du LOAD dans le temps, je suis tombé sur le billet Database Load heatmap with AWR and Python de Laurent Leturgez, qui, soit dit en passant, avoue lui-même avoir chercher une requête sur internet qui faisait déjà cela et il était tombé sur le blog de Marcin Przepiorowski.

Laurent Leturgez explique, dans son article, comment sortir le résultat de la requête en mode heatmap avec python. Le résultat est beau et effectivement les périodes les plus chargées ressortent bien.

Cependant cela nécessite d’installer un python, avec différents plugins adéquats pour le graphisme. Pour ma part, j’aurais préféré ne rien avoir à faire (aucune installation ou prérequis), juste à exécuter la requête dans un sqlplus sur le serveur voire un client… et c’est tout.

J’ai donc développé un script SQL/PL*SQL à partir de la requête initiale de Laurent Leturgez, pour générer le résultat sous forme d’un tableau HTML. Le script peut donc être lancé simplement sous SQL*PLUS et il génére un fichier HTML. Il est partagé sur cette page : >> Script sql : LOAD et AAS <<

La valeur ajoutée de ce script, en plus de faire un rapport graphique en HTLM, à la place d’un sortie TXT, et qu’il n’y a pas besoin de modifier la requête si l’on veut faire apparaitre la cartographie du LOAD, AAS, AAS_CPU ou AAS_WAIT. Le script demande lors de son exécution ce que l’on veut afficher. De plus suivant le choix, il va ajuster les seuils graphiques automatiquement.

Il est à noter aussi que j’ai modifié la ligne :

SELECT value AS core_nb FROM v$osstat WHERE stat_name='NUM_CPU_CORES'

Par

SELECT value AS core_nb FROM v$osstat WHERE stat_name='NUM_CPUS'

Contrairement à l’article de Laurent Leturgez, je ne prends pas en compte le nombre de cpu physique (colonne Cores dans un rapport AWR) mais le nombre de cpu actifs, c’est à dire le nombre total de cpu vu comme actif, donc hyperthreading inclus (colonne CPUs dans un rapport AWR). Je préfère me baser sur le nombre total de CPU actifs car dans un rapport AWR je prends toujours le rapport DB Time / Elapsed que je compare au nombre total de CPU pour faire une estimation de charge de la base par rapport à la puissance (capacité) théorique du serveur. De plus dans certain cas de serveur virtualisé, la vue v$osstat ne retourne pas de ligne pour stat_name='NUM_CPU_CORES', et la requête ne remonte alors aucune cartographie.

Ci-dessous, un exemple de résultat, ce n’est pas aussi design que le heatmap généré en python avec ses librairies graphique, mais c’est assez clair à lire :

La vue permet en un clin d’œil de connaitre les horaires sur lesquels il va falloir analyser les performances, ce qui peut faire gagner du temps sur un audit de base de données, et de plus cela fait toujours bien sur un rapport d’avoir de jolis graphiques quand on a rien à dire. La vue permet aussi de repérer facilement des occurrences dans le temps. Elle peut même orienter un début de recherche en comparant le AAS CPU au AAS WAIT, comme dans l’exemple ci-dessous, où l’on voit bien que lors de pic d’activité les sessions restent actives à cause d’événement de wait plutôt que CPU.