Dans LINQ-TO-SQL, devrais-je utiliser Nolock pour améliorer les performances?

Question

Notre DBA est venu à nous des informations que nos requêtes de Linq créent de nombreux milliers de serrures sur la base de données. Un développeur sur notre équipe a creusé ce post Hanselman comme solution possible à notre problème:

http://www.haselman.com/blog/gettinglinqtosqlandlinqtoentititiesteuseenolock.aspx < / p>

Scott fournit 3 façons de lire Nolock. 1) transactions (préférées), 2) SCROCS, 3) context.executeCommand

Nous sommes un site d'information à 99%, 1% écrit de sorte que notre objectif majeur est sur la vitesse de récupération. Est nolock une bonne stratégie pour toutes nos requêtes LINQ-TO-SQL?

Ce que j'essaie de comprendre est pourquoi utiliser Nolock est ou n'est pas une bonne idée. Il doit y avoir beaucoup de gens avec nos mêmes objectifs: beaucoup de lectures rapides, peu de mises à jour. Si Nolock est la réponse évidente, alors pourquoi n'est-ce pas la valeur par défaut? Pourquoi ne puis-je pas en faire une valeur par défaut sur le contexte, au lieu de devoir la définir dans chaque appel de données?

Nolock est vraiment la meilleure option pour les nombreuses lectures rapides, peu de mises à jour sur site?

Mise à jour: dans SQL Server 2005 et supérieur, est une isolation d'instantané mieux que Nolock? Je viens de trouver ça http://msdn.microsoft.com/en-us/library/ms179599.aspx

qui couvre Lire l'instantané engagé . Cela empêche le bloc d'écriture, mais ne retourne pas de données sales? Devrait-il être utilisé 90% du temps sur Nolock?

update 2: Qu'est-ce qui me dérange est sec

La partie qui me dérange la plupart est que, afin de mettre en œuvre un motif no-verrouillage ni un motif instantané, je dois le modifier sur chaque méthode de requête LINQ-TO-SQL (à l'exception de ceux utilisés dans les mises à jour). Cela sent une violation majeure de sec.

Answer 1

Worth noting: READ COMMITTED SNAPSHOT is (or at least was 2+ years ago) good enough for the site you're using.