230
Chapitre 7. Transactions et verrous
• SOS_SCHEDULER_YIELD – se produit lorsqu’une tâche s’interrompt volontairement pour redonner sa place, dans le modèle non prémptif de l’ordonnanceur
SQLOS. Voir cette entrée de blog pour plus de détails : http://
blogs.msdn.com/sqlcat/archive/2005/09/05/461199.aspx
Surveiller les attentes de verrous
Le compteur MSSQL:Wait statistics\Lock waits donne des informations importantes sur
les attentes en cours sur le système. sur les instances :
– Average wait time (ms) : Temps d’attente moyen par type.
– Cumulative wait time (ms) per second : temps total d’attente dans la seconde ;
– Waits in progress : nombre de processus en cours d’attente.
– Waits started per second : nombre d’attentes démarrées par seconde.
7.5 BLOCAGES ET DEADLOCKS
Nous avons présenté les attentes de façon générale, et nous avons vu qu’il y a
plusieurs types d’attentes. Les attentes spécifiques sur la libération de verrous par une
autre transaction, sont appelées des blocages : l’attente est involontaire, et dépend
d’une autre transaction. La transaction en attente détecte bien entendu cette situation, et elle se considère comme bloquée. Cette information de blocage est visible
dans les vues de gestion dynamique sys.dm os waiting tasks et sys.dm exec
requests (la colonne blocking_session_id y indique le sipd qui bloque la requête en
cours). Voici deux exemples de requêtes pour détecter les blocages :
SELECT session_id, wait_duration_ms, wait_type,
blocking_session_id, resource_description
FROM sys.dm_os_waiting_tasks
WHERE blocking_session_id IS NOT NULL;
SELECT blocked.session_id, st.text as blocked_sql,
blocker.session_id as blocker_session_id, blocker.last_request_end_time
FROM sys.dm_exec_requests blocked
JOIN sys.dm_exec_sessions blocker
ON blocked.blocking_session_id = blocker.session_id
CROSS APPLY sys.dm_exec_sql_text(blocked.sql_handle) st;
Bien sûr, une session qui est bloquée par une première, peut elle aussi en bloquer
une suivante, et ainsi de suite. Lorsque les verrous sont maintenus trop longtemps
sur des ressources, il peut se produire ainsi des chaînes de blocage qui finissent par
paralyser le serveur. Il est donc important de surveiller ces situations.
7.5.1 Détection des blocages par notification d’événements
Avant SQL Server 2005, le seul moyen pour surveiller et être averti de blocages
survenant sur le serveur, était de planifier une vérification régulière de la table
système sysprocesses. Cette approche est toujours possible. Vous pouvez placer
Chapitre 7. Transactions et verrous
• SOS_SCHEDULER_YIELD – se produit lorsqu’une tâche s’interrompt volontairement pour redonner sa place, dans le modèle non prémptif de l’ordonnanceur
SQLOS. Voir cette entrée de blog pour plus de détails : http://
blogs.msdn.com/sqlcat/archive/2005/09/05/461199.aspx
Surveiller les attentes de verrous
Le compteur MSSQL:Wait statistics\Lock waits donne des informations importantes sur
les attentes en cours sur le système. sur les instances :
– Average wait time (ms) : Temps d’attente moyen par type.
– Cumulative wait time (ms) per second : temps total d’attente dans la seconde ;
– Waits in progress : nombre de processus en cours d’attente.
– Waits started per second : nombre d’attentes démarrées par seconde.
7.5 BLOCAGES ET DEADLOCKS
Nous avons présenté les attentes de façon générale, et nous avons vu qu’il y a
plusieurs types d’attentes. Les attentes spécifiques sur la libération de verrous par une
autre transaction, sont appelées des blocages : l’attente est involontaire, et dépend
d’une autre transaction. La transaction en attente détecte bien entendu cette situation, et elle se considère comme bloquée. Cette information de blocage est visible
dans les vues de gestion dynamique sys.dm os waiting tasks et sys.dm exec
requests (la colonne blocking_session_id y indique le sipd qui bloque la requête en
cours). Voici deux exemples de requêtes pour détecter les blocages :
SELECT session_id, wait_duration_ms, wait_type,
blocking_session_id, resource_description
FROM sys.dm_os_waiting_tasks
WHERE blocking_session_id IS NOT NULL;
SELECT blocked.session_id, st.text as blocked_sql,
blocker.session_id as blocker_session_id, blocker.last_request_end_time
FROM sys.dm_exec_requests blocked
JOIN sys.dm_exec_sessions blocker
ON blocked.blocking_session_id = blocker.session_id
CROSS APPLY sys.dm_exec_sql_text(blocked.sql_handle) st;
Bien sûr, une session qui est bloquée par une première, peut elle aussi en bloquer
une suivante, et ainsi de suite. Lorsque les verrous sont maintenus trop longtemps
sur des ressources, il peut se produire ainsi des chaînes de blocage qui finissent par
paralyser le serveur. Il est donc important de surveiller ces situations.
7.5.1 Détection des blocages par notification d’événements
Avant SQL Server 2005, le seul moyen pour surveiller et être averti de blocages
survenant sur le serveur, était de planifier une vérification régulière de la table
système sysprocesses. Cette approche est toujours possible. Vous pouvez placer