J’ai eu il y a quelques temps la question suivante :

j’aimerais faire comprendre à mes développeurs l’intéret de positionner des NOLOCK dans les requêtes de sélection, peux-tu m’aider pour faire l’argumentaire

Pour rappel ou pour ceux qui ne voient pas de quoi je parle, NOLOCK est un Query Hint qui permet de passer le mode d’isolation au niveau le plus bas sur la lecture d’une table. Il s’utilise de la façon suivante :

Select * From MaTable WITH (NOLOCK)

Voici la réponse que j’ai donné :

Premièrement et c’est le plus important, utiliser NOLOCK n’est pas « naturel », dans le sens où la base de donnnées est là pour garantir les accès concurrents et gérer des lecture/écriture dans une optique transactionnelle (contraintes ACID¹) et ceux même pour un énorme volume de transactions.

Cependant, sans aller jusqu’à dire que c’est un constat d’échec que de l’utiliser, le hint NOLOCK est intéressant dans certains contextes.
Notamment les sites Web qui font beaucoup d’accès en lecture pour faire principalement de l’affichage. Dans ce cas, en effet, avoir une donnée non commitée n’est (en général) pas critique, sauf pour certains sites (bourses, état de stock, etc.). Cela permet de soulager la base de données et de booster l’affichage des pages.

Mais pour moi, le NOLOCK n’est qu’une réponse technique d’urgence et ne sert juste qu’à cacher la poussière sous le tapis. Il faut comprendre pourquoi l’ajout d’une ligne dans une facture bloque l’affichage du top 10 des vendeurs et essayer d’y répondre par la conception de l’application (cache, portée des transactions, etc.) ou de la base (normalisation/dénormalisation).
J’insiste qu’il y a un risque à utiliser NOLOCK à tout va, car on peut récupérer des données « dirty » et les réécrire par la suite et perdre la cohérence (aCid); à l’application d’adresser cette contrainte.

Donc pour conclure :

• le NOLOCK est une réponse technique intéressante pour optimiser l’affichage de données NON CRITIQUES
• l’utilisation systématique du NOLOCK n’est pas une bonne chose car elle cache un réel problème transactionnel. Et surtout on ne respecte plus la « norme » ACID.

Si tu utilises SQL Server 2005, il faut te tourner vers les autres niveaux de verrou comme le Snapshot (READ_COMMITTED_SNAPSHOT) qui apporte la souplesse en lecture tout en garantissant les transactions (comme le fait Oracle). Un bon argument pour passer à 2005.

¹ACID: Atomicité, Cohérence, Isolation, Durabilité