Quelqu'un pourrait-il me donner des conseils sur le moment où je devrais utiliser WITH (NOLOCK)plutôt queSET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
Quels sont les avantages / inconvénients de chacun? Y a-t-il des conséquences imprévues que vous avez rencontrées en utilisant l'un par opposition à l'autre?
Réponses:
Ce sont les mêmes choses. Si vous utilisez l' set transaction isolation levelinstruction, elle s'appliquera à toutes les tables de la connexion, donc si vous ne voulez nolockqu'une ou deux tables, utilisez-la; sinon utilisez l'autre.
Les deux vous donneront des lectures sales. Si cela vous convient, utilisez-les. Si vous ne pouvez pas avoir de lectures sales, pensez à snapshotou à des serializableconseils à la place.
WITH (NOLOCK) est un indice au niveau de la table. La définition du niveau d'isolement de transaction sur READ_UNCOMMITTED affecte la connexion. La différence est en termes de portée. Voir READUNCOMMITTED et NOLOCK dans la documentation SQL Server ici:
http://technet.microsoft.com/en-us/library/ms187373.aspx
Pour le NIVEAU D'ISOLATION DES TRANSACTIONS: http://technet.microsoft.com/en-us/library/ms173763.aspx
En ce qui concerne les directives ... une recherche aléatoire à partir de StackOverflow et de l'interweb électrique ...
À ma connaissance, la seule différence est la portée des effets, comme l'a dit Strommy. NOLOCK pointe sur une table et le READ UNCOMMITTED sur la session.
Quant aux problèmes qui peuvent survenir, c'est une question de cohérence. Si vous vous en souciez, sachez que vous pourriez obtenir ce que l'on appelle des lectures incorrectes qui pourraient influencer d'autres données manipulées sur des informations incorrectes.
Personnellement, je ne pense pas avoir vu de problèmes à ce sujet, mais cela peut être davantage dû à la façon dont j'utilise nolock. Vous devez être conscient qu'il existe des scénarios dans lesquels il sera possible de l'utiliser. Scénarios dans lesquels vous ajoutez principalement de nouvelles données à une table, mais un autre processus intervient pour vérifier un scénario de données. Ce sera probablement OK car le flux principal n'inclut pas le retour en arrière et la mise à jour des lignes lors d'une lecture.
Je crois également que ces jours-ci, vous devriez vous pencher sur le contrôle de la concurrence multi-version. Je crois qu'ils l'ont ajouté en 2005 et cela aide à empêcher les rédacteurs de bloquer les lecteurs en donnant aux lecteurs un aperçu de la base de données à utiliser. Je vais inclure un lien et laisser plus de recherches au lecteur:
Comme vous devez utiliser WITH (NOLOCK) pour chaque table, il peut être ennuyeux de l'écrire dans chaque clause FROM ou JOIN. Cependant, il a une raison pour laquelle on l'appelle une lecture "sale". Vous devez donc vraiment savoir quand vous en faites une, et ne pas la définir par défaut pour la portée de la session. Pourquoi?
Oublier un WITH (NOLOCK) peut ne pas affecter votre programme de manière très dramatique, cependant faire une lecture sale là où vous n'en voulez pas peut faire la différence dans certaines circonstances.
Utilisez donc WITH (NOLOCK) si les données actuelles sélectionnées sont autorisées à être incorrectes, car elles pourraient être annulées plus tard. Ceci est principalement utilisé lorsque vous souhaitez augmenter les performances, et les exigences du contexte de votre application lui permettent de prendre le risque que des données incohérentes soient affichées. Cependant, vous ou un responsable devez peser le pour et le contre de la décision d'utiliser WITH (NOLOCK).
REPEATABLE READplutôt queSERIALIZABLEsi vous ne vous souciez pas des données fantômes.SERIALIZABLEest VRAIMENT restrictif et ne devrait presque jamais être utilisé (sauf par exemple dans certaines applications financières critiques).