Considerações sobre o NOLOCK ao ler dados do BD

(...) 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. (...)

Autor: Gustavo Maia Aguiar
Post original:  http://social.msdn.microsoft.com/Forums/pt-BR/520/thread/49c83f8a-0dad-406d-9163-411472325a23/