Tip 7 : Comprenez le verrouillage

et pendant combien de temps il maintient les verrous. Après avoir bien compris la manière dont SQL Server pratique le verrouillage et le blocage, on pourra écrire des applications qui travaillent avec SQL Server plutôt que contre lui.

Ainsi, après que l’application modifie les données dans une transaction, SQL Server verrouille ces données et les refuse à  tout autre processus jusqu’à  ce que vous engagiez (commit) ou repreniez (rollback) la transaction. Si l’on met longtemps à  émettre une commande commit ou rollback, les données seront verrouillées longuement. D’où les deux conseils suivants : garder les transactions aussi courtes que possible et interdire à  tout utilisateur d’intervenir au milieu de la transaction.

Par défaut, SQL Server maintient des verrous exclusifs – acquis lorsqu’on insère, met à  jour et supprime des données – jusqu’à  la fin d’une transaction. SQL Server ne maintient des verrous de partage (share) – acquis lors de la sélection des données – que jusqu’au moment où l’on finit de lire les données sélectionnées.

On peut modifier le niveau d’isolation des transactions pour amener SQL Server à  maintenir les verrous de partage jusqu’à  la fin d’une transaction. Cela signifie qu’une fois les données extraites et lues, personne d’autre ne peut les modifier. Il peut paraître judicieux de modifier les niveaux d’isolation des transactions pour réserver les données à  son propre usage. Mais ces modifications sont néfastes pour des systèmes multi-utilisateurs dans lesquels de nombreux utilisateurs ont besoin d’accéder aux mêmes données. Je conseille de laisser le niveau d’isolation des transactions à  Committed Read (qui est d’ailleurs le niveau d’isolation des transactions par défaut) et de ne changer le niveau que quand c’est le seul moyen d’atteindre les objectifs de performances fixés.