OBJECTIFS DES ANALYZERS D.SIDE
Les Analyzers de d.side, 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 expliquer ce qui en est la cause, afin de travailler sur les éléments responsables de cette situation.
OBJECTIFS DU LOCKS ANALYZER
Dans le cas du Locks Analyzer, un excès est lié à un blocage ou une contention pendant l’exécution de requêtes ou de transactions.
Cela peut par exemple se traduire par :
- Une session en train de bloquer une ou plusieurs autres sessions
- Des verrous posés au niveau d’une ligne
- Des verrous posés au niveau d’une table
- Un objet sur lequel de nombreux verrous sont posés
- Des contentions au niveau du library cache, de la zone de shared pool
- Une procédure qu’on essaie de compiler et d’utiliser en même temps
- Un ralentissement qui se traduit par une attente plus longue sur un verrou
- Un temps de traitement applicatif prolongé pendant qu’un verrou est posé par SELECT FOR UPDATE
Le Locks Analyzer va permettre d’observer qui bloque qui, sur quoi, depuis combien de temps, afin de détecter par exemple si une session, un objet ou une requête sont responsables de blocages.
COMMENT UTILISER LE LOCKS ANALYZER
L’élément principal de ce Locks and Dependencies Analyzer est l’arbre des dépendances.
LOCKS TREE
Cette zone, sous la forme d’un arbre, présente les sessions qui dépendent les unes des autres.
Dans l’exemple ci-dessus le Locks Analyzer indique que :
- La situation observée est considérée par d.side comme une problématique de verrou. C’est pour cette raison que l’icone à la racine de cet arbre est un verrou.
- La session 63 est en train de bloquer deux autres sessions (191 et 194) sur un verrou de type “enqueue TX – row lock contention”
- Dans le cas des enqueues, une description complète du type de verrou rencontré est donnée. Ici, “TX” correspond à une transaction.
- La session 191 attend sur ce verrou enqueue TX depuis plus d’une seconde
- La session 194 est bloquée sur ce verrou depuis un peu moins de 20 secondes
Les informations affichées sont mises à jour à chaque nouveau snapshot d.side, après chaque intervalle (toutes les 5 secondes par défaut).
Pour plus de confort de lecture, il est parfois utile de cocher la case “Freeze Refresh” pour figer le contenu de cet arbre des dépendances. Cela évite qu’il soit mis à jour en permanence.
En double-cliquant ou en utilisant le clic droit sur une ligne du « Locks Tree » on peut obtenir plus de détails sur la session choisie.
SESSION INFO
Par exemple, double-cliquer ou choisir l’entrée “SID Info” dans le menu contextuel (bouton droit) amène dans une fenêtre “Session Info” qui permet de suivre en détails la session sélectionnée.
SESSION LOCKED OBJECTS
Via le bouton droit, l’entrée “Locked Objects” ouvre une fenêtre “Locked Objects” pour la session choisie. On y observe tous les verrous positionnés par cette session :
ROW | OBJECT INFO
Le menu “Row Info” du bouton droit permet quant à lui d’obtenir les informations précises concernant l’objet en cause dans la dépendance. On récupérera même le ROWID s’il s’agit d’un verrou au niveau ligne comme dans le cas d’une enqueue TX :
Le bouton “Row Info” dans le cadre d’une attente de type “library cache lock” indiquera plutôt quelle procédure est en cours d’utilisation pendant qu’on essaie de la recompiler, par exemple, entraînant une situation de verrouillage d’un autre type que de l’enqueue relative à une transaction.
GLOBAL LOCKED OBJECTS
Concernant les objets verrouillés, on peut également cliquer sur le bouton “Locked Objects”.
Cela ouvre une fenêtre “Locked Objects List” permettant de voir en un coup d’oeil quels objets sont verrouillés, combien de fois chacun.
Par exemple ici la table PARAMETERS du schéma CUSTAPPLI est impliquée dans 2 attentes sur verrou (valeur 2 dans la colonne “Locked Sessions”), ce qui correspond à 100% des verrous comptabilisés sur cette instance (la barre de progression dans cette même colonne est pleine).
On détecte ainsi très facilement si une session ou un objet est responsable d’une part importante de tous les verrous positionnés.
Et si cela a du sens, on peut également descendre au niveau de la partition, dont le nom apparaîtrait alors dans la colonne “Sub Object Name”.
DEADLOCKS
Cela est très rare mais la situation a déjà été rencontrée quelques fois, Oracle peut sous certaines conditions de charge ou de bug, ne pas détecter un deadlock et laisser deux sessions en attente indéfiniment.
Pour pallier ce défaut, d.side propose au travers de son bouton “Deadlock detection” une recherche des sessions qui pourraient être concernées par une telle situation.
RAC OPTION
Si l’option d.side RAC est souscrite et que plusieurs instances sont impliquées dans une situation de blocage, il est alors possible de naviguer d’une instance à l’autre très facilement, de manière automatique. Si l’option n’est pas souscrite, l’utilisateur ne peut observer qu’une instance à la fois.
COMMENT OUVRIR LE LOCKS ANALYZER
Le Locks Analyzer est accessible depuis le menu Analyzers de d.side :
Complément : si en plus, l’option d.side RAC est activée, alors le Locks Analyzer offre d’emblée une vision complète des dépendances de sessions sur tout le cluster. Sinon, sans cette option, l’utilisateur est contraint de vérifier les dépendances sur chaque noeud du cluster RAC.
Une autre manière d’ouvrir le Locks Analyzer est de double-cliquer dans la liste “Wait Events” de l’écran principal de d.side sur un événement d’attente impliquant du verrouillage ou de la dépendance entre sessions.
Par exemple un événement d’attente du type “enqueue” comme “enq:TX”, ou un événement d’attente comme “library cache lock” peut amener l’utilisateur dans le Locks Analyzer.
EXEMPLES D’UTILISATION
CAS 1 : lock
Si on reprend la situation affichée au début de cet article, les informations présentées par le Locks Analyzer mettent bien en évidence un problème de verrou.
On a d’ailleurs le dessin d’un verrou à la racine de l’arbre des dépendances “Locks Tree”.
CAS 2 : performance issue
Les informations présentées par le Locks Analyzer mettent cette fois-ci en évidence un problème de performance.
La session 191 bloque les sessions 63 et 194 depuis un peu plus d’une seconde sur un verrou de type enqueue TX, mais les verrous observés ne sont que la conséquence du problème de performances. Les attentes ne sont que le symptôme.
En affichant cette fois une icone en forme de chronomètre, d.side nous met sur la piste de la performance, pas du verrouillage “simple”. Inutile donc de killer les sessions en jeu, et notamment la session 191 dans le cas présent, cela ne devrait pas résoudre le problème. Mieux vaut retourner sur l’écran principal de d.side et dans d’autres Analyzers pour rechercher l’origine de ce ralentissement.
CAS PARTICULIER DU LIBRARY CACHE LOCK
Lorsqu’une attente de type “library cache” est détectée, d.side détermine s’il s’agit d’une situation de blocage entre sessions, ou si les performances sont dégradées du fait de contentions en shared pool.
– Dans le premier cas, l’utilisateur est aiguillé vers le Locks Analyzer pour obtenir tous les détails concernant qui bloque qui, depuis combien de temps, sur quel objet…
– Dans le second cas, la contention amène l’utilisateur dans le Shared Pool Analyzer pour observer les éléments Oracle qui pourraient aider à comprendre ce qui provoque la dégradation. Pour plus d’informations concernant le fonctionnement et l’interprétation des données du Shared Pool Analyzer, nous vous invitons à consulter l’article dédié : https://www.dside-software.com/blog-shared-pool-analyzer/.
CONCLUSION
Les situations de verrouillage ou de dépendance entre sessions sont fréquentes dans la vie d’une application utilisant une base de données relationnelle.
L’objectif du Locks Analyzer de d.side est de déterminer si la situation observée est normale, acceptable ou si elle correspond à un problème ayant une incidence sur le bon fonctionnement de l’application. La distinction faite entre une situation de verrouillage et un problème de performance permet de gagner beaucoup de temps dans cette analyse. De plus, le Locks Analyzer met à disposition toutes les informations permettant d’identifier très facilement et très rapidement les éléments en jeu pour affiner l’analyse de la situation : sessions, requêtes, objets, ROWID des lignes…
