No LINQ-To-SQL, devo usar NOLOCK para melhorar o desempenho?

Question

Nosso DBA veio até nós com a informação de que nossas consultas LINQ estão criando milhares de bloqueios no banco de dados.Um desenvolvedor de nossa equipe desenterrou esta postagem de Hanselman como uma possível solução para nosso problema:

http://www.hanselman.com/blog/GettingLINQToSQLAndLINQToEntitiesToUseNOLOCK.aspx

Scott fornece três maneiras no LINQ para configurar o NOLOCK.1) TransactionScope (preferencial), 2) SPROCS, 3) context.ExecuteCommand

Somos um site de notícias que 99% lê e 1% escreve, então nosso foco principal está na velocidade de recuperação.É NÃO FECHE uma boa estratégia para todas as nossas consultas LINQ-TO-SQL?

O que estou tentando entender é por que usar NOLOCK é ou não uma boa ideia.Deve haver muitas pessoas com nossos mesmos objetivos:muitas leituras rápidas, pouca ou nenhuma atualização.Se NOLOCK é a resposta óbvia, por que não é o padrão?Por que não posso torná-lo padrão no contexto, em vez de ter que defini-lo em cada chamada de dados?

O NOLOCK é realmente a melhor opção para sites com muitas leituras rápidas e poucas atualizações?

ATUALIZAR:No SQL Server 2005 e superior, o isolamento do Snapshot é melhor que o NOLOCK?Acabei de encontrar issohttp://msdn.microsoft.com/en-us/library/ms179599.aspx

que cobre LEIA O INSTANTÂNEO COMPROMETIDO.Isso evita o bloqueio de gravação, mas não retorna dados sujos?Isso deve ser usado 90% do tempo em vez do NOLOCK?

ATUALIZAÇÃO 2:O que está me incomodando é SECO

A parte que mais me incomoda é que, para implementar um padrão sem bloqueio ou de instantâneo, preciso alterá-lo em CADA método de consulta LINQ to SQL (exceto aqueles usados ​​em atualizações).Isso cheira a uma violação grave do DRY.

Answer 1

Vale nada: READ COMMITTED SNAPSHOT é (ou pelo menos era há mais de 2 anos) bom o suficiente para o site que você está usando.