C’est la pratique de mauvais NOLOCK (soupçon de Sql Server) ?

Question

Je suis dans le secteur de la préparation du site et des applications qui ne sont pas essentielles à la mission -> par exemple. logiciel bancaire, l'espace de vol et de soins intensifs, de surveillance de l'application, etc. Vous obtenez l'idée.

Donc, avec cette énorme avertissement, est-il mauvais à l'aide de l'indicateur NOLOCK dans certains instruction Sql? Un certain nombre d'années, il a été suggéré par un membre de l'Administrateur Sql que je devrais utiliser NOLOCK si je suis heureux avec un dirty read .. ce qui me donnera un peu plus de la performance de mon système, car chaque lecture n'est pas verrouiller le tableau/ligne/quoi que ce soit.

On m'a aussi dit que c'est une excellente solution si je suis en train de vivre dead-locks (grincer des dents). Donc, j'ai commencé à suivre cette idée pendant quelques années jusqu'à ce qu'un Sql guru m'aider avec quelques code aléatoire et remarqué que toutes les NOLOCKS dans mon code sql. J'ai été poliment grondé et il a essayé de me l'expliquer (pourquoi c'est pas une bonne chose) et je sorta suis perdu :( je sentais que l'essence de son explication était " c'est un band-aid solution à un problème plus grave .. surtout si vous êtes victime d'interblocage. En tant que tel, fixer la racine du problème".

J'ai fait quelques recherches sur google récemment à ce sujet et suis tombé sur ce post.

Ainsi, certains sql db gourou sensei, merci de m'éclairer? Être belle .. je suis blonde :( donc, allez-y doucement, genre monsieur/madame.

cheers :)

Answer 1

Avant de travailler sur un Débordement de Pile j'étais contre NOLOCKS sur le principe que vous pourriez éventuellement effectuer une sélection avec NOLOCK et obtenir les résultats avec des données qui peuvent être obsolètes ou incompatibles. Un facteur de réfléchir à la manière dont de nombreux enregistrements peuvent être Insérées ou mises à Jour en même temps un autre processus peut être la Sélection de données à partir de la même table. Si cela se produit beaucoup, alors il y a une forte probabilité de blocages, sauf si vous utilisez une base de données en mode de LECTURE ENGAGE INSTANTANÉ.

Depuis, j'ai changé mon point de vue sur l'utilisation de NOLOCK après avoir été témoin de la façon dont il peut améliorer SÉLECTIONNEZ la performance ainsi que d'éliminer les blocages sur un massivement chargé de SQL Server. Il ya des moments que vous ne pouvez pas les soins que vos données n'est pas exactement 100% engagé et vous avez besoin des résultats rapidement, même si elles peuvent être obsolètes.

Posez-vous la question quand on pense à l'aide de NOLOCK - ma requête inclure un tableau qui comporte un grand nombre d'Insertions, Mises à jour et je m'en fiche si les données renvoyées par une requête peut être manquant à ces changements, à un moment donné, si la réponse est NON, que vous pourriez utiliser NOLOCK pour améliorer les performances.

J'ai juste effectué une recherche rapide pour la NOLOCK mot-clé dans la base de code pour le Débordement de la Pile et a trouvé 138 cas-si nous l'utilisons dans pas mal d'endroits.

Answer 2

Avec indicateur NOLOCK, le niveau d'isolation de transaction pour l' SELECT déclaration est - READ UNCOMMITTED. Cela signifie que la requête peut voir sale et des données incohérentes.

Ce n'est pas une bonne idée d'appliquer la règle. Même si cette sale comportement de la lecture est OK pour votre mission critique pour l'application basée sur le web, un NOLOCK analyse peut causer 601 erreur qui va mettre fin à la requête en raison d'un mouvement de données en raison du manque de protection de verrouillage.

Je suggère la lecture Lors de l'Isolement d'Instantané de l'Aide et Quand Ça fait Mal - la MSDN recommande d'utiliser READ committed plutôt que SHAPSHOT dans la plupart des circonstances.

Answer 3

Si vous n'avez pas de soins sur les lectures erronées (c'est à dire dans un essentiellement en LECTURE de la situation), alors NOLOCK est fine.

MAIS, sachez que la majorité des problèmes de verrouillage sont dues à ne pas avoir la "bonne" index pour votre requête de la charge de travail (en supposant que le matériel est à la hauteur de la tâche).

Et le gourou de l'explication était la bonne. Il est généralement une bande-aide de la solution d'un problème plus grave.

Edit: je ne suis certainement pas ce qui suggère que NOLOCK doit être utilisé. Je suppose que je devrais avez fait que de toute évidence claire. (Je n'en ai jamais utiliser, dans des circonstances extrêmes où j'avais analysé que c'était OK). COMME un exemple, un temps, j'ai travaillé sur certains TSQL qui avait été aspergé avec NOLOCK à soulager les problèmes de verrouillage. J'ai enlevé tous, mis en œuvre le bon index, et TOUS les blocages s'en alla.

Answer 4

Doute qu'il était un "gourou" qui avait eu une expérience dans la grande circulation...

Les sites web sont généralement "sale" au moment où la personne est la visualisation de l'complètement chargées de la page. Envisager une forme de charges à partir de la base de données et enregistre les données éditées?? C'est idiot de la façon dont les gens aller sur sale lit étant un non non.

Cela dit, si vous avez un certain nombre de couches de bâtiment sur votre sélection, vous pourrez construire une dangereuse redondance. Si vous avez affaire à de l'argent ou le statut de scénarios, alors vous ne devez pas seulement les données sur les opérations de lecture/écriture, mais une bonne simultanéité de la solution de (quelque chose de la plupart des "gourous" ne vous embêtez pas avec).

D'autre part, si vous avez un moteur de recherche avancé pour un site web (c'est à dire quelque chose qui ne sera probablement pas mis en cache et être un peu intensive) et vous avez déjà créé un site avec plus que quelques utilisateurs simultanés (phenominal comment de nombreux "experts" n'ont pas), il est ridicule de goulot de bouteille tous les autres processus derrière elle.

Sais ce que cela signifie et de les utiliser au moment opportun. Votre base de données sera presque toujours être votre principal goulot de ces jours et être intelligent sur l'utilisation de NOLOCK vous pouvez économiser des milliers dans les infrastructures.

EDIT: Ce n'est pas seulement des blocages elle les aide, c'est aussi la façon dont beaucoup vous allez faire de tout le monde, attendre jusqu'à ce que vous avez terminé, ou vice versa.

À l'aide de NOLOCK information dans EF4?

Answer 5

Aucune réponse n'est mal, mais un peu confus peut-être.

• Lors de l'interrogation des valeurs uniques/lignes c'est toujours une mauvaise pratique à utiliser NOLOCK -- vous n'avez probablement jamais souhaitez afficher des informations incorrectes ou peut-être même prendre des mesures sur des données incorrectes.
• Lors de l'affichage des bruts de l'information statistique, NOLOCK peut être très utile. Prendre un exemple: Il serait absurde de tirer les verrous de lire l' exact nombre de vues sur une question, ou le nombre exact de questions pour un tag. Personne ne se soucie si vous tort 3360 questions tagged avec "sql-server" maintenant, et en raison d'une annulation de la transaction, 3359 questions une seconde plus tard.