Dynamics AX : Diagnostiquer les problèmes de verrouillage (locks) - PART 1

Dans le passé, j’ai écrit un billet au sujet des blocs dans votre base de données SQL, aujourd'hui je voulais approfondir le sujet.

Comme nous l'avons vu, il est possible de savoir les sessions SQL bloquées. De plus, nous sommes capables d'associer la session SQL (SPID) avec la session AX lorsque connectioncontext est activé sur le serveur AOS. 

Aujourd’hui, je veux savoir pourquoi la session est bloquée.

Afin de faire la démonstration, je vais volontairement créer un blocage dans la base de données. Dans ma première requête, je vais mettre à jour le champ ENABLE pour le ID mathieu. Toutefois, je ne vais pas commettre la transaction immédiatement, ceci aura pour effet de verrouiller la ligne pour une durée de 30min.

(SPID 78)

BEGIN TRANSACTION

UPDATE USERINFO SET ENABLE=1 WHERE ID = 'mathieu.'

    WAITFOR DELAY '00:30:00' 

ROLLBACK TRANSACTION

Dans la seconde requête, je vais tenter de faire une modification à la même ligne:

(SPID 80)

UPDATE USERINFO SET ENABLE=0

WHERE ID = 'mathieu.'

En utilisant cette requête, je suis capable de voir que mes deux requêtes sont en cours d’exécution :

RunningQueries.sql

En utilisant la requête suivante, je peux voir que le SPID 78 bloque le SPID 80. 

QueriesWaiting.sql

Dans ce cas-ci, nous pouvons voir que le SPID 78 est bloqué à cause de la commande WAITFOR. Nous pouvons aussi voir que le SPID 80 attend après le SPID 78 afin d'acquérir un lock de type Update (LCK_M_U).

J'aimerais avoir plus d’information à ce sujet et pour ceci nous pouvons vérifier les locks dans la base de données:  

Locks.sql

Je peux voir que la session 80 attend pour obtenir un lock de type U sur la ressource (362b1400cd67). La raison est parce que la session 78 a déjà un lock de type X sur la même ressource. Un lock de type X est incompatible avec les autres lock, pour cette raison, la session 80 doit attendre. Vous pouvez lire plus au sujet des compatibilités entre lock ici: Lock Compatibility

Je vois que le type de ressource est KEY. Ceci veut dire que le lock est sur une ligne. Vous pouvez lire plus au sujet des différents types de ressource  ici: sys.dm_tran_locks (Transact-SQL). Afin de connaître la ligne, vous pouvez exécuter cette requête. 

KeyLock.sql

SELECT sys.fn_PhysLocFormatter(%%physloc%%) AS FilePageSlot, 

%%lockres%% AS LockResource, *

FROM USERINFO

WHERE %%lockres%% ='(362b1400cd67)' 

Et voilà, maintenant je sais que la session 80 attend après la session 78 afin de mettre a jour la ligne suivante: