Comment puis-je prouver que NOLOCK est la source de problèmes de blocage?

Je n'essaie pas de démarrer une discussion de type Windows / Mac.

Personnellement, je n'ai pas besoin de convaincre, ce NOLOCKn'est pas une bonne idée comme pratique réflexive. Il semble que lorsque vous développez, tout devrait être utile et non réactionnaire (/ amen)

Alors ... le programmeur responsable insiste sur NOLOCKla voie à suivre. Recommande avec toutes les requêtes ad hoc et chaque fois que vous interrogez la production. Je n'ai pas vu de procédure stockée sans indice nolock sur chaque table.

Je ne veux pas être ce gars qui arrive et dit à tout le monde qu'une croyance fondamentale est fausse sans quelque chose pour la sauvegarder.

En regardant les sessions de commentaires sous les différents articles de blog, l'envoi d'un lien peut ne pas être suffisant. Des croyances anciennes, etc ... Certaines personnes ne sont pas convaincues que ce soit un problème. Voir la section Commentaires sous chaque article de blog nolock que j'ai lu.

Actuellement, d'autres DBA se débattent avec un blocage mystérieux. Comment déterminer si les NOLOCK sont la source?

Il a été suggéré de regarder XML à partir de traces, etc., mais cela n'indiquera pas explicitement que les blocages sont à l'origine du problème, n'est-ce pas? Je n'ai jamais vu de messages d'erreur aussi simples. Est-ce vrai?

Sinon, comment ces blocages pourraient-ils être épinglés?

Les déclarations DDL comme CREATEseraient un indice. Y a-t-il des sorties sur lesquelles je pourrais pointer ou des données que je pourrais trouver qui pourraient corroborer ma théorie avant de déclencher l'alarme?

Ou suis-je en train d'exécuter des indicateurs de trace ou des événements étendus pour identifier ce qui fonctionne lorsque les blocages se produisent, puis déduire des instructions DDL?

En regardant toutes les différentes façons dont les données peuvent être gâchées avec des astuces nolock, il semble difficile de déterminer de manière décisive.

L'architecte en chef insiste sur NOLOCKla voie à suivre. Recommande avec toutes les requêtes ad hoc et chaque fois que vous interrogez la production. Je n'ai pas vu de sproc sans indice nolock sur chaque table.

Désolé d'entendre ça. Ceci est assez bien universellement considéré comme un anti-modèle parmi les praticiens experts de SQL Server, mais vous ne pouvez rien faire pour changer les faits sur le terrain si la pratique est vraiment ancrée et basée sur les croyances sincères et profondément ancrées d'une personne. .

La question dit que "l'envoi d'un lien peut ne pas être suffisant", mais on ne sait pas ce que vous voulez à la place. Nous pourrions écrire l'argument le plus convaincant du monde dans une réponse ici, et il vous resterait encore "l'envoi d'un lien". En fin de compte, personne ici ne peut savoir quel ensemble d'arguments réussira dans votre situation spécifique (le cas échéant).

Néanmoins, ce qui suit couvre la plupart des points que certaines personnes jugent suffisamment convaincants pour changer une pratique auparavant courante:

• Mauvaises habitudes: mettre NOLOCKpartout par Aaron Bertrand
• NOLOCKAstuce SQL Server et autres mauvaises idées Par David Lean (Microsoft)
• Le niveau d'isolement lu non engagé par moi
• Justifiez de NE PAS utiliser l'indication (nolock) dans chaque requête (questions et réponses connexes ici)

Même ainsi, vous ne pourrez peut-être pas «gagner» cette bataille. J'ai travaillé dans un environnement qui a fait cela, j'ai compris les risques et les raisons de ne pas le faire, mais j'ai quand même continué avec ça. C'étaient des gens brillants et logiques, mais au final c'était un environnement dans lequel je ne pouvais pas être heureux de travailler.

Actuellement, d'autres DBA se débattent avec un blocage mystérieux. Comment peut-on déterminer qui NOLOCKssont la source.

Le schéma le plus courant (peut-être plus répandu dans le passé) en ce sens que des NOLOCKindices sont introduits pour tenter de réduire l'incidence des blocages. Cela peut `` fonctionner '' dans la mesure où la réduction du nombre de verrous partagés pris réduit naturellement les chances que des verrous incompatibles soient pris, mais ce n'est pas une bonne solution au problème sous-jacent et est livré avec toutes les mises en garde notées dans la section précédente.

Néanmoins, les NOLOCKindices peuvent introduire de nouvelles façons de bloquer. L'utilisation de l'isolement de lecture non validée peut supprimer une condition de blocage transitoire (résolue lorsque la ressource contenue devient disponible) dans un blocage non résolu (où aucun serveur ne peut progresser) simplement parce que la contention se produit maintenant à un point différent, où par exemple les opérations d'écriture dans un ordre différent chevauchement. Dave Ballantyne en a un exemple ici:

• Accroissement des blocages avec NOLOCK

Pour des conseils plus généraux sur la gestion des blocages, je recommande ce qui suit comme point de départ:

• La difficulté avec les impasses par Jeremiah Peschka

Vous devez également vous familiariser avec la documentation:

• Blocage (et les trois sous-sujets là-bas)

Autres ressources utiles:

• Blocages SQL Server par exemple par Gail Shaw
• Résolution des problèmes de blocage par Bart Duncan