In Linq-to-SQL, dovrei usare NOLOCK per migliorare le prestazioni?

Question

Il nostro DBA è venuto a noi con informazioni che le nostre query LINQ stanno creando molte migliaia di blocchi sul database. Uno sviluppatore del nostro team ha scavato questo post di Hanselman come possibile soluzione al nostro problema:

http://www.hanselman.com/blog/gettinglinqtosqlandlinqtoentosqtosqlandlinqto.px < / P >.

Scott offre 3 modi in LINQ per l'impostazione di NOLOCK. 1) TransactionScope (preferito), 2) sprocs, 3) context.executecommand

Siamo un sito di notizie che è il 99% di letture, scrive all'1% in modo che il nostro obiettivo principale sia sulla velocità del recupero. Nolock Una buona strategia per tutte le nostre query Linq-to-SQL?

Che cosa sto cercando di capire è Perché usando Nolock è o non è una buona idea. Ci devono essere molte persone con i nostri stessi obiettivi: molte letture veloci, poco a nessun aggiornamento. Se Nolock è la risposta ovvia, allora perché non è il valore predefinito? Perché non riesco a renderlo predefinito nel contesto, invece di doverlo impostare in ogni singola chiamata dati?

è Nolock davvero l'opzione migliore per le molte letture veloci, pochi aggiornamenti sito?

Aggiornamento: in SQL Server 2005 e oltre, è l'isolamento dell'istantanea migliore rispetto a Nolock? Ho appena trovato questo http://msdn.microsoft.com/en-us/library/ms179599.aspx

che copre Leggi istantanea commessa . Questo impedisce il blocco di scrittura, ma non restituisce i dati sporchi? Questo dovrebbe essere usato il 90% delle volte su Nolock?

Aggiornamento 2: Cosa mi infastidisce è secco

La parte che mi infastidisce di più è che per implementare un modello senza chiusura o snapshot, devo cambiarlo su ogni metodo di query linq-to-sql (ad eccezione di quelli utilizzati negli aggiornamenti). Questo odora di una grande violazione di secco.

Answer 1

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