Catégories: Vues Système, V$SESSION_WAIT

Cet article est la traduction d'un article de Jonathan Lewis publié sur son blog. L'article original en anglais se trouve ici.
Il précise la signification des colonnes WAIT_TIME et SECONDS_IN_WAIT dans V$SESSION et V$SESSION_WAIT, en fonction de la colonne STATE
Ces vues donnent un moyen rapide pour diagnostiquer une session qui semble bloquée, et savoir si elle est en attente d'un appel système (wait events) ou en CPU.

Un post récent sur le forum OTN fait le commentaire suivant: “le wait event est: latch shared pool, et la CPU est à 100%, il tourne depuis quelques heures et semble bloqué...”

Cela me rappelle une erreur commise fréquemment lorsque les gens regardent la vue V$SESSION_WAIT s'ils oublient de regarder la valeur de la colonne STATE.

Ce que vous devriez vérifier se trouve dans la requête suivante:

select sid, state, event, wait_time, seconds_in_wait from v$session_wait

Lorsque vous interprétez le résultat, souvenez-vous que la session n'est en train d'attendre que si la colonne STATE est exactement à 'WAITING'.
Sinon, c'est que la session est en CPU (ou pour être plus précis techniquement, dans la runqueue) et n'est pas en train d'attendre sur un wait event.

Si STATE montre autre chose que 'WAITING', alors la différence entre SECONDS_IN_WAIT et WAIT_TIME donne approximativement (à 3 secondes près puisque la valeur est mise à jour à peu près toutes les 3 secondes) le temps deuis lequel la session est en CPU, ou plus précisément dans la runqueue, depuis la fin du dernier wait event.

A noter: cela vous montre que cette colonne SECONDS_IN_WAIT est très mal nommée, et devrait plutôt être appelée
'nombre_de_secondes_depuis_le_debut_du_dernier_wait_avec_une_erreur_jusqua_trois_secondes', mais il y a une limite de 32 caractères pour les noms de colonnes.

A noter aussi que depuis la 10g, on peut aussi faire cette requête sur V$SESSION au lieu de V$SESSION_WAIT

» Lire la suite!