Ocasionalmente, recebo "Não foi possível continuar a verificação NOLOCKdevido à movimentação de dados" em alguns trabalhos grandes, que existem WITH (NOLOCK)nas consultas selecionadas.
Entendo que isso tem algo a ver com a tentativa de selecionar dados quando houve uma divisão de página que fez com que os dados não estivessem mais onde deveriam estar - presumo que é isso que está acontecendo no meu ambiente.
Como eu reproduzi isso?
Estou tentando fazer uma solução alternativa de curto prazo para detectar o erro e tentar novamente quando isso acontecer, mas não posso testá-lo se não conseguir reproduzi-lo. Existe uma maneira razoavelmente confiável de causar isso?
Quando isso acontece, a execução da consulta novamente resulta em sucesso - então eu realmente não tenho nenhuma preocupação sobre os dados ou banco de dados reais estarem permanentemente corrompidos. Algumas das tabelas da consulta (junto com seus índices) são descartadas, recriadas e repovoadas com frequência, então estou assumindo que é algo relacionado a isso.
A remoção NOLOCKé o meu problema de longo prazo. O motivo NOLOCKfoi colocado lá em primeiro lugar, porque as consultas são tão ruins que estavam travando as transações diárias, assim NOLOCKcomo um band-aid para interromper os impasses (que funcionavam). Então, eu preciso de um band-aid em um band-aid até que possamos fazer uma solução permanente.
Se eu pudesse reproduzi-lo com um Hello World, provavelmente planejaria colocar o curativo no trabalho em menos de uma hora. Não é possível fazer uma remoção de pesquisar e substituir NOLOCK, porque eu começaria a obter os impasses do aplicativo novamente, o que é pior para mim do que um trabalho ocasional com falha.
Usar o isolamento de snapshot confirmado por leitura é uma boa possibilidade - terei que trabalhar com nossa equipe de banco de dados para obter mais detalhes sobre isso. Parte do nosso problema é que não temos um especialista em SQL Server para lidar com esse tipo de coisa e não entendo os níveis de isolamento suficientemente bem para fazer essa alteração agora.
DEADLOCK_PRIORITYpara LOWnos postos de trabalho, de modo que se houver impasses, os postos de trabalho irá falhar, e não as aplicações. Depois disso, você pode pesquisar os impasses e descobrir por que eles estão acontecendo e resolver o problema. Pode ser uma correção muito simples, como trocar a ordem de duas instruções. Qualquer que seja o problema, essa nãoNOLOCK é a solução , então pare de tentar forçá-lo a ser apenas porque é mais fácil.
NOLOCKesses trabalhos? 601 deve ser a menor das suas preocupações se os resultados dessas consultas forem precisos . Paul White mostra um exemplo particularmente terrível de leitura de dados que não deveria ser possível aqui .