Le NOLOCK (indice Sql Server) mauvaise pratique?
https://stackoverflow.com/questions/1452996
-
12-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je suis dans l'entreprise de faire le site web et les applications qui sont pas mission critique -> par exemple. logiciel bancaire, vol spatial, l'application de surveillance des soins intensifs, etc. Vous avez l'idée.
Alors, avec cette mise en garde massif, est-il mauvais en utilisant l'indicateur NOLOCK dans une déclaration Sql? Plusieurs années auparavant, il a été suggéré par un collègue Sql administrateur que je devrais utiliser NOLOCK si je suis heureux avec une « lecture sale » qui va me donner un peu plus de performance de mon système, car chaque lecture ne se verrouille pas la tableau / ligne / whatever.
On m'a aussi dit que c'est une excellente solution si je suis dans des impasses. Donc, je commencé à suivre cette pensée pendant quelques années jusqu'à ce qu'un gourou Sql me aide avec un code aléatoire et remarqué tous les NOLOCKS dans mon code sql. Je poliment réprimandé et il a essayé de me l'expliquer (pourquoi ce n'est pas une bonne chose) et je me suis perdu sorta. Je sentais que l'essence de son explication était «c'est une solution sparadrap à un problème plus grave .. surtout si vous rencontrez interblocage. En tant que tel, fixer la racine du problème.
Je l'ai fait googling récemment à ce sujet et suis tombé sur ce post.
Ainsi, certains peuvent gourou db sql Sensei s'il vous plaît me éclairer?
La solution
Avec indicateur NOLOCK, le niveau d'isolation des transactions pour le compte de SELECT est READ UNCOMMITTED. Cela signifie que la requête peut voir les données sales et incohérentes.
Ce n'est pas une bonne idée d'appliquer en règle. Même si ce comportement est sale lecture OK pour votre application web mission critique, une analyse NOLOCK peut provoquer une erreur 601 qui mettra fin à la requête en raison du mouvement de données en raison d'un manque de protection de verrouillage.
Je vous suggère de lire Lorsque l'isolement instantané aide et quand il Hurts - MSDN recommande l'utilisation LIRE INSTANTANÉ ENGAGE plutôt que dans la plupart des cas INSTANTANÉ.
Autres conseils
Avant de travailler sur Stack Overflow, j'étais contre NOLOCK sur le principe que vous pourriez potentiellement effectuer une SELECT avec NOLOCK et retourner des résultats avec des données qui peuvent être périmées ou incompatibles. Un facteur à penser est le nombre d'enregistrements peuvent être insérés / mis à jour en même temps un autre processus peut être la sélection des données de la même table. Si cela se produit beaucoup alors il y a une forte probabilité d'interblocages sauf si vous utilisez un mode de base de données tels que READ COMMITED SNAPSHOT .
Je l'ai depuis changé mon point de vue sur l'utilisation de NOLOCK après avoir vu comment il peut améliorer les performances de SELECT ainsi que d'éliminer sur un serveur blocages SQL massivement chargé. Il y a des moments que vous ne pouvez pas veiller à ce que vos données ne sont pas exactement 100% engagé et vous avez besoin des résultats de retour rapidement, même si elles peuvent être à jour.
Demandez-vous une question en pensant à l'aide NOLOCK:
Est-ce que ma requête comprend une table qui a un nombre élevé de commandes
INSERT/UPDATEet me importe si les données renvoyées à partir d'une requête peut manquer ces changements à un moment donné?
Si la réponse est non, utilisez NOLOCK pour améliorer les performances.
Je viens d'effectuer une recherche rapide pour le mot-clé
NOLOCK dans la base de code pour débordement de pile et trouvé 138 cas, nous utilisons donc dans un bon nombre de lieux.
Si vous ne se soucient pas de lit sale (à savoir dans une situation essentiellement READ), puis NOLOCK est très bien.
et , sachez que la majorité des problèmes de verrouillage sont dus à ne pas avoir les indices « corrects » pour votre charge de travail de requête (en supposant que le matériel est à la tâche).
Et l'explication du gourou était correcte. Il est généralement une solution sparadrap à un problème plus grave.
Modifier : Je ne suis certainement pas ce qui suggère que NOLOCK devrait être utilisé. Je suppose que je devrais avoir fait que de toute évidence claire. (Je n'utiliser que jamais il, dans des circonstances extrêmes où je l'avais analysé qu'il était OK). A titre d'exemple, un certain temps, je travaillais sur certains TSQL qui avait été saupoudré de NOLOCK pour essayer de réduire les problèmes de verrouillage. Je les ai enlevé tous, mis à exécution les bons index, et tous les blocages partais.
doute était-il un « gourou » qui avait eu une expérience dans le trafic élevé ...
Les sites Web sont généralement « sale » au moment où la personne consulte la page complètement chargée. Considérons une forme qui se charge de la base de données et les données sont sauvegardées qui est ?? éditables Il est idiot la façon dont on ne cessent de parler sale lit étant un non non.
Cela dit, si vous avez un certain nombre de couches bâtiment sur votre sélectionne, vous pourriez être la construction d'une redondance dangereuse. Si vous traitez dans des scénarios d'argent ou de statut, alors vous avez besoin non seulement des données transactionnelles lecture / écriture, mais une solution de concurrence d'accès (quelque chose plus « gourous » ne vous embêtez pas avec).
Par contre, si vous avez une recherche de produit avancé pour un site Web (c.-à quelque chose qui ne sera probablement pas mises en cache et être un peu intense) et que vous avez déjà construit un site avec plus de quelques utilisateurs simultanés ( phenominal combien « experts » ont pas), il est rediculous à la bouteille cou tous les processus derrière elle.
ce que cela signifie et l'utiliser, le cas échéant. Votre base de données sera presque toujours votre principal goulot de la bouteille ces jours-ci et être intelligent sur l'utilisation NOLOCK peut vous faire économiser des milliers dans les infrastructures.
EDIT:. Il est non seulement DEADLOCKS il aide à, il est aussi combien vous allez faire tout le monde attendre jusqu'à ce que vous avez terminé, ou vice versa
Aucune des réponses ne va pas, mais un peu confus peut-être.
- Lorsque vous interrogez des valeurs uniques / lignes, il est toujours mauvaise pratique à utiliser NOLOCK -. Vous voulez probablement jamais afficher des informations incorrectes ou peut-être même prendre toute mesure sur des données incorrectes
- Lors de l'affichage des informations statistiques bruts, NOLOCK peut être très utile. Alors, prenez comme exemple: Il serait absurde de prendre des verrous pour lire le exact nombre de vues d'une question, ou le nombre exact de questions pour une étiquette. Personne ne se soucie si vous déclarez correctement les questions 3360 tagués avec « sql-server » maintenant, et à cause d'une annulation de la transaction, 3359 questions une seconde plus tard.
En tant que développeur professionnel, je dirais que cela dépend. Mais je suis certainement l'AGCS et des conseils OMG Poneys. Sachez ce que vous faites, de savoir quand il aide et quand ça fait mal et
lire conseils et autres idées pauvres
ce qui pourrait vous faire comprendre plus profondément le serveur SQL. Je suis généralement la règle que SQL Conseils sont mal, mais malheureusement, je les utilise tous maintenant et puis quand je me marre forcer le serveur SQL faire des choses ... Mais ce sont des cas rares.
luke
app-soutien voulu répondre ad-jarret requêtes à partir du serveur de production à l'aide SSMS (qui ne sont pas pris en charge par des rapports) j'ai demandé qu'ils utilisent nolock. De cette façon, l'entreprise « principale » n'est pas affectée.
Je suis d'accord avec certains commentaires au sujet de soupçon NOLOCK et surtout avec ceux qui disent « l'utiliser quand il est approprié ». Si la demande écrite mal et utilise de façon inappropriée de concurrence - qui peut provoquer l'escalade de verrouillage. table transactionnelle sont également très verrouillé se tout le temps en raison de leur nature. Avoir une bonne couverture d'index ne sera pas aider à récupérer les données, mais la définition du niveau de ISOLEMENT à LIRE UNCOMMITTED fait. Je crois aussi que l'utilisation de soupçon NOLOCK est sûr dans de nombreux cas où la nature des changements est prévisible. Par exemple - dans le secteur manufacturier où les emplois avec les voyageurs passent par différents processus avec beaucoup d'inserts de mesure, vous pouvez sans risque d'exécuter la requête contre le travail fini avec indication NOLOCK et ainsi éviter une collision avec d'autres sessions qui mettent les verrous PROMUS ou exclusif sur la table /page. Les données que vous accédez dans ce cas est statique, mais il peut résider dans une table très transactionnel avec des centaines de millions d'enregistrements et des milliers mises à jour / insertions par minute. Vive
Je crois qu'il est pratiquement jamais correct d'utiliser nolock.
Si vous lisez une seule ligne, l'index correct signifie que vous ne aurez pas besoin NOLOCK que les actions de ligne individuelles sont complétées rapidement.
Si vous lisez plusieurs lignes pour autre chose que l'affichage temporaire, et se soucient de pouvoir répéter le résultat ou la défense par le nombre produit, alors NOLOCK ne convient pas.
NOLOCK est une balise de remplacement pour « Je ne me soucie pas si cette réponse contient des lignes en double, des lignes qui sont supprimés, ou des lignes qui ont jamais été insérées pour commencer à cause de rollback »
Les erreurs qui sont possibles sous NOLOCK:
- Les lignes qui ne sont pas retournés correspondance du tout.
- les lignes simples sont retournés plusieurs fois (y compris plusieurs instances de la même clé primaire)
- Les lignes qui ne correspondent pas sont renvoyés.
Toute action qui peut provoquer une page divisée alors que le nolock sélectionnez est en cours d'exécution peut provoquer ces choses se produire. Presque toute action (même une suppression) peut provoquer une scission de la page.
Par conséquent:. Si vous « savez » que la ligne ne sera pas modifiée pendant que vous utilisez, ne pas utiliser nolock, comme un indice permettra une récupération efficace
Si vous pensez que la ligne peut changer pendant que la requête est en cours d'exécution, et vous vous souciez de précision, ne pas utiliser nolock.
Si vous envisagez de NOLOCK en raison de blocages, examiner la structure du plan de requête pour les analyses de table inattendues, tracer les blocages et pourquoi ils se produisent. NOLOCK écrit autour peut signifier que les requêtes qui, auparavant, interblocage seront potentiellement à la fois écrire la mauvaise réponse.
Les meilleures solutions, lorsque cela est possible sont les suivants:
- Répliquer vos données (en utilisant le log-réplication) à une base de données de rapports.
- Utilisez des instantanés SAN et monter une version cohérente du DB
- Utilisez une base de données qui a un meilleur niveau fondamental d'isolation des transactions
Le niveau d'isolation des transactions SNAPSHOT a été créée parce que MS a été en train de perdre des ventes à Oracle. Oracle utilise undo / redo logs pour éviter ce problème. Postgres utilise MVCC. Dans l'avenir MS de Heckaton utilisera MVCC, mais c'est des années loin d'être prêt pour la production.
NOLOCK est souvent exploitée comme un moyen magique pour accélérer la base de données lit, mais j'essaie d'éviter de l'utiliser whever possible.
Le jeu de résultats peut contenir des lignes qui n'ont pas encore été commis, qui sont souvent roulaient plus tard en arrière.
Une erreur ou d'un ensemble de résultats peut être vide, soit des lignes manquantes ou présentent la même ligne plusieurs fois.
Ceci est parce que d'autres transactions sont données en mouvement en même temps que vous le lisez.
READ COMMITTED ajoute un problème supplémentaire où les données sont endommagées dans une seule colonne où plusieurs utilisateurs changent la même cellule simultanément.
Dans la vraie vie où vous rencontrez des systèmes déjà écrit et l'ajout d'index aux tables puis ralentit de façon drastique le chargement de données d'une table de données de 14gig, vous êtes parfois contraints de utilisé avec NOLOCK sur vos rapports et à la fin de proessing mois afin que l'ensemble funtions (somme, compter, etc.) ne font pas la ligne, la page, le verrouillage de table et deteriate la performance globale. Facile à dire dans un nouveau système ne jamais utiliser avec des index de NOLOCK et d'utilisation - mais l'ajout d'index déclassements severly chargement des données, et quand je suis alors dit, eh bien, de modifier la base de code pour supprimer des index, puis charge en vrac puis recréez les indices - qui est très bien, si vous développez un nouveau système. Mais pas quand vous avez un système déjà en place.
