Prós e contras do WITH(NOLOCK).

Question

 

Alguem poderia me dizer os prós e contras de se usar WITH(NOLOCK)?

Answer 1

Olá,

 

Isso depende do que você quer fazer e do que precisa.

 

A grosso modo, ele é equivalente ao READUNCOMMITTED, ou seja, você pode ler registros que ainda não foram comitados e também a consulta não entrará em lock.

 

Procure por READUNCOMMITTED no BOL para informações mais detalhadas.

 

Abraços

 

Answer 2

Olá Rogério, não existe esse negócio de prós e contra de se usar o hint NOLOCK. Se vc souber o que ele é e o que faz, então, saberá aplicá-lo no momento certo e as implicações de usá-lo.

 

Não tem uma receita de bolo.

 

Basicamente, o NOLOCK só realiza "1" coisa: Permite que vc realize a leitura de dados não comitados(Dirty read), ou seja, dados que estão sendo manipulados e ainda não foram confirmados.

 

O uso do NOLOCK é válido em situações onde os dados retornados por cláusulas que usam o "with nolock" não manipulem aquela informação, porque, aquela informação não é segura, pode estar sofrendo auterações por outras transações.

 

Recomento que vc dê uma lida em um artigo que fala sobre os efeitos de concorrências entre transações.

Seguinte link:

http://msdn.microsoft.com/en-us/library/ms190805.aspx

 

 

Answer 3

Olá RogerioJun,

 

Quando se fala em controle de concorrência, existem duas óticas: a pessimista e a otimista. O uso do NOLOCK só se aplica a ótica pessimista (não faz nenhum sentido utilizá-lo na ótica otimista e por isso não irei descrevê-la).

 

A ótima pessimista acredita que alguém sempre estará interessado em realizar comandos de escrita (update, delete e insert) e para evitar problemas, ela impõe bloqueios tanto nas operações de leitura quanto nas operações de escrita. Isso significa que quando alguém estiver lendo, ninguém pode atualizar e quando alguém estiver atualizando ninguém pode ler.

 

Do ponto de vista da consistência isso é ótimo, pois, ninguém irá ler dados não comitados e assim garante-se que as leituras são mais consistentes. Do ponto de vista de concorrência isso é péssimo, pois, irá impor maiores tempos de espera, pois, ler e escrever impõe bloqueios e esperas um ao outro.

 

Quando você utiliza o NOLOCK, as operações de leitura não impõe nenhum tipo de bloqueio, elas simplesmente lêem os dados. O grande ponto positivo é que as operações de leitura não tem mais de esperar, basta simplesmente ler. Outro ponto positivo (em menor grau) é que se as leituras não impõe bloqueios, o SQL Server não terá que gastar recursos gerenciando esses bloqueios.

 

Como nem tudo são flores, há conseqüências. Quando você utiliza o NOLOCK e acessa os dados diretamente (sem ter de impor bloqueios), você estará fazendo uma leitura inconsistente em potencial. Imagine duas transações (T1 e T2) com o seguinte comportamento:

 

10:00 - T1 inicia

10:01 - T2 inicia

10:02 - T1 atualiza o registro com ID = 1

10:03 - T2 lê o registro com ID = 1

10:04 - T1 faz rollback

10:05 - T1 finaliza

10:06 - T2 finaliza

 

Isso significa que T2 leu dados que T1 mudou, mas T1 desfez esses dados posteriormente. Em linhas gerais, T2 leu dados que nunca existiram.

 

O uso do NOLOCK implica em abrir mão da consistência em nome da melhor concorrência e tem suas aplicabilidades. Se você deseja um relatório estatístico com pouca precisão ele é aplicável, pois, não irá impor bloqueios nas atualizações. Se você deseja uma informação muito precisa, você não deve utilizá-lo. Em todo caso é sempre necessário avaliar ao invés de utilizá-lo por default.

 

No SQL Server 2005 temos a mão recursos de concorrência otimista (snapshot isolation e read committed snapshot) que resolvem o problema da consistência sem gerar bloqueios.

 

[ ]s,

 

Gustavo

Answer 4

Rogério,

 

Dizer se existem prós ou contras em relação aos mecanismos de isolamento de dados, curiosamente a maioria das pessoas acreditam que utilizar este tipo de recurso poderá trazer benéficios ou fatores de risco, isso é uma situação que requer uma análise e detalhamento do objetivo sobre o qual deseja utilizar este recurso.

 

Basicamente o NoLock é um tipo de TableHint, que tem por objetivo indicar a uma table que a mesma deverá ou não permitir a leitura de dados que ainda não foram considerados verdadeiros, ou seja, informações que ainda não foram confirmadas, como também dependendo da maneira que o NoLock é utilizar permitir que a mesma informação que esta sendo acessada por uma sessão esteja disponível para outro, possibilitando que a mesma seja manipulada por comandos de Inserção, Atualização ou Deleção.

 

Cabe a sua análise e lógicamente alguns testes para identificar como você poderá aplicar este recurso.

Answer 5

Obrigado ao pessoal que respodeu. Minha dúvida residia no fato de aqui na empresa, para toda e qualquer situação de performance nosso consultador enfiava WITH(NOLOCK) de cima abaixo nas stored procedures. E eu fiquei com um pé atrás com essa solução.

Answer 6

Bom, como não podemos julgá-lo, recomendo questioná-lo sobre o(s) motivo(s) que o levaram a tomar essa decisão.

 

Grande abraço, e boas festas!

Answer 7

Rogério,

 

Obrigado pelo retorno, estaremos sempre a disposição.

Answer 8

Pelo que ele me explicou quando questionei, ele me disse que isso não travaria a tabela que estava sendo lida, e que isso resolveria grande parte dos casos de DEADLOCK que estamos tendo.

Answer 9

Olá Rogério,

 

É uma situação bem típica, mas na maioria das vezes errada.

 

É certo que o NOLOCK beneficia o desempenho do servidor, uma vez que ao utilizá-lo, os bloqueios de leitura não serão colocados e menos bloqueios é mais memória disponível e menos esperas. Se há menos esperas, não só o desempenho como o tempo de resposta também melhora. Só que se o uso do NOLOCK melhora o desempenho e o tempo de resposta, por que então ele não é o padrão ? Acredito que essa foi a parte que o consultor talvez não tenha lhe dito. O correto não é dizer "O NOLOCK melhora o desempenho porque não gera LOCK" mas sim "O NOLOCK melhora o desempenho porque não gera LOCK, mas piora a concorrência porque pode ler dados sujos. Se o negócio tolerar essa leitura, ele pode ser interessante".

 

Não posso responder porque para qualquer situação ele fez isso (embora tenha um forte palpite), mas acho que utilizar o NOLOCK tem que levar em conta o efeito na consistência. Não basta ter um banco rápido. É preciso ter um banco certo. Soluções generalizadas podem não levar em conta certas particularidades. Será que toda consulta pode abrir mão da concorrência ?

 

Vale a pena lembrar também que trabalhar para melhorar o desempenho segue alguns passos e que o NOLOCK seria um dos últimos. Se o objetivo é perfomance, é melhor começar pela base, ou seja, rever o modelo de dados, as consultas e a indexação. São aspectos que provocam um ganho muito superior em relação ao NOLOCK.

 

Vale a pena lembrar que no 2005, o Read Commited Snapshot e o Snapshot Isolation Level são alternativas muito mais interessantes em relação ao NOLOCK do ponto de vista de consistência.

 

[ ]s,

 

Gustavo

 

Answer 10

Em relação ao HINT NOLOCK, segue 3 Links bem interessantes,

Se ficar alguma dúvida é só falar que se for o caso escrevo mais sobre isso no meu blog,

http://blogs.msdn.com/sqlserverstorageengine/archive/2006/11/09/when-can-allocation-order-scans-be-used.aspx
http://www.sqlmag.com/article/articleid/92887/sql_server_blog_92887.html
http://sqlblogcasts.com/blogs/tonyrogerson/archive/2006/11/10/1280.aspx