Comme dans tout SGBD, il se peut qu’une session bloque un objet, empêchant ainsi les autres sessions de travailler dessus, les mettant donc en attente. C’est ce que nous appelons un lock.
Pour trouver le responsable de ce dernier, nous allons dans un premier temps utiliser la procédure stockée « sp_who2 ».
Elle nous permettra de voir les différentes sessions bloquées en nous indiquant la fautive :
On peut constater que la session bloquante initiale est la 57.
Nous pouvons également récupérer le Login utilisé par la session, le DBName (base sur laquelle est lancé la requête), le type de commande…
Pour notre session 57, le champ ProgramName nous indique que cette dernière correspond à l’agent SQL Server et plus particulièrement, un job.
Nous allons voir de quel job il s’agit avec la requête suivante :
select * from msdb..sysjobs where job_id = 0x6E6EB18998743E42BA740122351F7BE7
Il s’agit d’un job d’import comptable, ce dernier est à l’origine de la succession de locks.
Pour débloquer la situation, il faudra attendre qu’il se termine, ou l’arrêter/tuer la session (avec accord du client). Un rollback sera effectuer et lorsqu’il sera terminé, il n’y aura plus de lock.
Poussez-l’analyse un peu plus loin.
Avec la procédure stockée sp_WhoIsActive, il sera possible de récupérer les requêtes des sessions actives :
Il est également possible de voir le login_time de la session et le start_time de la requête :
On peut donc constater que notre session bloquante a lancé sa requête le 01/11/2019 à 06h00 du matin, ce qui correspond avec la planification du job.