Les verrous mortels, connus sous SQL Server comme « deadlocks », se produisent lorsque deux processus utilisateur ont posé des verrous sur des objets distincts, et que chacun de ces deux processus tente d’acquérir un nouveau verrou sur un objet que l’autre processus a déjà verrouillé.

Quand le moteur de SQL Server identifie un tel phénomène, il met fin à la transaction la moins coûteuse en ressources à défaire (ROLLBACK)

Quelles sont les règles de base à suivre pour éviter les problèmes de verrous mortels ?

Lorsqu’un verrou mortel est relevé par le moteur de base de données de SQL Server, celui-ci choisit la transaction la moins coûteuse à « rollbacker », puis retourne un message au client du processus qui a initié la transaction. Cela permet à l’autre transaction de continuer à s’exécuter.

Comme vous pouvez l’imaginer, outre le fait que les verrous mortels nécessitent d’être retraités par une gestion d’erreurs appropriée, ils sont gourmands en ressources CPU.

Voici quelques règles simples pour éviter les verrous mortels :

=> S’assurer que le modèle de données de la base de données est proprement normalisé

=> S’assurer que l’indexation des tables a été proprement effectuée

=> Dans les modules SQL, accéder les objets de base de données toujours dans le même ordre

=> Lors de la spécification de transactions explicites (BEGIN TRANSACTION), veiller à ce que celles-ci soient les plus courtes possibles.

Pour cela :

– Il ne faut pas que les transactions soient en attente d’une saisie utilisateur (les données utilisateur doivent être collectées avant le début de la transaction)

– Il faut réduire le nombre d’aller-retours entre l’application et la base de données (par l’utilisation de procédures stockées notamment)

– Il ne faut lire les données qu’une seule fois. Une méthode pour éviter cela est d’utiliser les expressions de table commune

– Réduire au maximum le temps de verrouillage : l’application doit acquérir des verrous le plus tard possible et les libérer le plus tôt possible

– Si cela est approprié, limitez l’escalade de verrous avec les indicateurs de table ROWLOCK et PAGLOCK

– Si cela est approprié, utilisez l’indicateur de table NOLOCK (données rarement modifiées)

– Si cela est approprié, utilisez un niveau d’isolation de transaction aussi faible que possible

Notons qu’en tout état de cause, SQL Server gère très bien les verrous et les transactions seul.

ElSuket