Le conseil NOLOCK (SQL Server) est-il une mauvaise pratique?
Je suis en train de créer des sites Web et des applications qui ne sont pas essentielles à la mission -> par exemple. logiciel bancaire, vol spatial, application de surveillance des soins intensifs, etc. Vous voyez l'idée.
Donc, avec cet énorme disclaimer, est-il mauvais d'utiliser l'indicateur NOLOCK dans une déclaration SQL? Il y a quelques années, un administrateur de SQL m'a suggéré d'utiliser NOLOCK si je suis satisfait d'une "lecture sale" qui me donnera un peu plus de performances de mon système, car chaque lecture ne verrouille pas le lecteur. table/ligne/peu importe.
On m'a également dit que c'était une excellente solution si je vivais dans une impasse. Alors, j'ai commencé à suivre cette pensée pendant quelques années jusqu'à ce qu'un gourou Sql m'aide avec un code aléatoire et remarque tous les NOLOCKS dans mon code SQL. J'ai été poliment réprimandé et il a essayé de me l'expliquer (pourquoi ce n'est pas une bonne chose) et je me suis un peu égaré. J’ai eu l’impression que son explication était essentiellement la suivante: "C’est une solution miracle à un problème plus grave… surtout si vous rencontrez une impasse. En tant que tel, corrigez la racine du problème '.
J'ai récemment fait des recherches sur Google et suis tombé sur ce post .
Alors, certains sql db guru sensei peuvent-ils m'éclairer?
Avec NOLOCK Hint, le niveau d'isolation de transaction pour l'instruction SELECT est READ UNCOMMITTED. Cela signifie que la requête peut voir des données modifiées et incohérentes.
Ce n'est pas une bonne idée d'appliquer en règle générale. Même si ce comportement de lecture incorrecte est correct pour votre application Web essentielle à la mission, une analyse NOLOCK peut provoquer une erreur 601 qui mettra fin à la requête en raison du transfert de données dû au manque de protection de verrouillage.
Je suggère de lire Lorsque l'isolement d'instantané aide et quand ça fait mal - le MSDN recommande d'utiliser LIRE INSTANTANÉ COMMITTE plutôt que SNAPSHOT dans la plupart des circonstances.
Si vous ne vous souciez pas des lectures sales (c'est-à-dire dans une situation à prédominance READ), alors NOLOCK ira bien.
MAIS , sachez que la majorité des problèmes de verrouillage sont dus au fait de ne pas disposer des index "corrects" pour votre charge de travail de requête (en supposant que le matériel soit à la hauteur de la tâche ).
Et l'explication du gourou était correcte. C'est généralement une solution miracle à un problème plus grave.
Edit: Je ne suggère absolument pas d’utiliser NOLOCK. J'imagine que j'aurais dû le préciser clairement. (Je ne l'utiliserais que dans des circonstances extrêmes où j'avais analysé que tout allait bien). À titre d’exemple, il ya quelque temps, j’ai travaillé sur des TSQL arrosées de NOLOCK pour tenter d’atténuer les problèmes de verrouillage. Je les ai tous supprimés, mis en place les index corrects et TOUTES les impasses ont disparu.
Douter que ce soit un "gourou" qui ait eu une expérience dans le trafic intense ...
Les sites Web sont généralement "sales" au moment où la personne consulte la page complètement chargée. Considérons un formulaire qui se charge à partir de la base de données, puis enregistre les données modifiées ?? C'est idiot la façon dont les gens parlent de lectures sales étant un tel non non.
Cela dit, si vous avez un certain nombre de couches sur votre sélection, vous risquez de créer une redondance dangereuse. Si vous avez affaire à des scénarios d'argent ou de statut, vous avez besoin non seulement de lecture/écriture de données transactionnelles, mais également d'une solution de simultanéité appropriée (ce que la plupart des "gourous" n'ennuient pas).
Par contre, si vous recherchez un site Web avec un produit avancé (c’est-à-dire quelque chose qui ne sera probablement pas mis en cache et sera un peu intensif) et que vous avez déjà construit un site avec plus de quelques utilisateurs simultanés (nombre phénoménal), "experts" ne l'ont pas), il est ridicule de mettre tous les autres processus derrière.
Sachez ce que cela signifie et utilisez-le le cas échéant. Votre base de données sera presque toujours votre principal goulot de bouteille de nos jours et l'utilisation intelligente de NOLOCK peut vous faire économiser des milliers de dollars en infrastructure.
EDIT: Les aides ne sont pas une impasse, c'est aussi combien vous allez faire attendre les autres jusqu'à la fin, ou inversement.
Aucune des réponses n’est fausse, mais un peu déroutant peut-être.
- Lorsque vous interrogez des valeurs/lignes individuelles, il est toujours mauvaise pratique d'utiliser NOLOCK - vous ne souhaiterez probablement jamais afficher des informations incorrectes, ni même entreprendre une action sur des données incorrectes.
- Lorsque vous affichez des informations statistiques approximatives, NOLOCK peut être très utile. Prenons par exemple SO: il serait illogique de prendre des verrous pour lire le nombre exact de vues d’une question ou le nombre exact de questions pour une balise. Personne ne s'inquiète si vous énoncez incorrectement les questions 3360 portant la mention "serveur SQL" maintenant, et à cause d'une annulation de transaction, 3359 questions une seconde plus tard.
En tant que développeur professionnel, je dirais que cela dépend. Mais je suis certainement les conseils de GATS et OMG Ponies. Sachez ce que vous faites, savez quand cela vous aide et quand cela fait mal et
lire astuces et autres mauvaises idées
ce qui pourrait vous faire comprendre le serveur SQL plus en profondeur. Je suis généralement conforme à la règle voulant que les astuces SQL soient EVIL, mais malheureusement, je les utilise de temps en temps lorsque j'en ai marre de forcer SQL Server à faire des choses ... Mais ce sont des cas rares.
luke
Les meilleures solutions, quand c'est possible, sont:
- Répliquez vos données (à l'aide de la réplication de journal) dans une base de données de rapports.
- Utilisez les instantanés SAN et montez une version cohérente de la base de données
- Utiliser une base de données ayant un meilleur niveau d'isolation fondamental des transactions
Le niveau d'isolation SNAPSHOT de la transaction a été créé car MS perdait des ventes au profit d'Oracle. Oracle utilise les journaux d'annulation/restauration pour éviter ce problème. Postgres utilise MVCC. À l'avenir, Heckaton de MS utilisera MVCC, mais il faudra des années avant d'être prêt pour la production.
Lorsque l'application de support a voulu répondre aux requêtes ad-hock du serveur de production à l'aide de SSMS (qui n'étaient pas prises en charge via le reporting), j'ai demandé à ce qu'elles utilisent nolock. De cette façon, l'activité principale n'est pas affectée.
Je suis d'accord avec certains commentaires sur l'indice NOLOCK et en particulier avec ceux qui disent "utilisez-le quand c'est approprié". Si l'application écrit mal et utilise la concurrence de manière inappropriée, cela peut provoquer l'escalade de verrous. Les tables hautement transactionnelles sont également bloquées tout le temps en raison de leur nature. Avoir une bonne couverture d'index n'aidera pas à récupérer les données, mais définir ISOLATION LEVEL sur READ UNCOMMITTED le permet. De plus, je pense que l'utilisation de NOLOCK hint est sans danger dans de nombreux cas lorsque la nature des changements est prévisible. Par exemple, dans le secteur de la fabrication lorsque les tâches impliquant des voyageurs passent par différents processus comportant de nombreuses insertions de mesures, vous pouvez exécuter en toute sécurité une requête sur la tâche finie avec NOLOCK hint et ainsi éviter la collision avec d'autres sessions qui placent des verrous PROMOTED ou EXCLUSIVE sur la table. /page. Les données auxquelles vous accédez dans ce cas sont statiques, mais elles peuvent résider dans une table très transactionnelle contenant des centaines de millions d'enregistrements et des milliers de mises à jour/insertions par minute. À votre santé
Je crois qu'il n'est pratiquement jamais correct d'utiliser nolock.
Si vous lisez une seule ligne, le bon index signifie que vous n’aurez pas besoin de NOLOCK car les actions de chaque ligne s’effectuent rapidement.
Si vous lisez plusieurs lignes pour autre chose qu'un affichage temporaire et que vous vous souciez de pouvoir répéter le résultat ou de défendre par le nombre généré, alors NOLOCK n'est pas approprié.
NOLOCK est une balise de substitution pour "peu m'importe si cette réponse contient des lignes en double, des lignes supprimées ou des lignes qui n'ont jamais été insérées pour commencer à cause de la restauration"
Erreurs possibles sous NOLOCK:
- Les lignes qui correspondent ne sont pas renvoyées du tout.
- une seule ligne est renvoyée plusieurs fois (y compris plusieurs instances de la même clé primaire)
- Les lignes qui ne correspondent pas sont retournées.
Toute action pouvant entraîner le fractionnement d'une page pendant l'exécution de noLock select peut entraîner ces problèmes. Presque toutes les actions (même une suppression) peuvent entraîner une division de la page.
Par conséquent: si vous "savez" que la ligne ne sera pas modifiée pendant votre exécution, n'utilisez pas nolock, car un index permettra une extraction efficace.
Si vous pensez que la ligne peut changer pendant l'exécution de la requête et que l'exactitude vous tient à cœur, n'utilisez pas nolock.
Si vous envisagez NOLOCK en raison de blocages, recherchez dans la structure du plan de requête des analyses de table inattendues, tracez les blocages et voyez pourquoi ils se produisent. NOLOCK autour des écritures peut signifier que des requêtes précédemment bloquées écriront potentiellement la mauvaise réponse.
NOLOCK est souvent exploité comme un moyen magique d’accélérer les lectures de bases de données, mais j’essaie d’éviter de l’utiliser autant que possible.
L'ensemble de résultats peut contenir des lignes qui n'ont pas encore été validées, qui sont souvent ultérieurement restaurées.
Une erreur ou un ensemble de résultats peut être vide, être des lignes manquantes ou afficher la même ligne plusieurs fois.
En effet, d’autres transactions déplacent des données en même temps que vous les lisez.
READ COMMITTED ajoute un problème supplémentaire dans lequel les données sont corrompues dans une seule colonne lorsque plusieurs utilisateurs changent simultanément la même cellule.