Ao tentar executar meu plano de manutenção, recebo o seguinte erro:
A execução da consulta "" falhou com o seguinte erro: "O índice "" (partição 1) na tabela "" não pode ser reorganizado porque o bloqueio no nível da página está desabilitado."
No momento, temos o bloqueio de nível de linha ativado neste índice. Posso ativar o bloqueio no nível da página, mas não tenho certeza de quais são as repercussões.
Minha pergunta é: qual é a diferença entre os dois esquemas de bloqueio e quais são suas consequências no mundo real (em produção)?
O plano de manutenção deve estar tentando um ALTER INDEX REORGANIZE, que é uma operação online. Para remover a fragmentação (páginas fora de ordem), as páginas devem ser bloqueadas e movidas, o que não é possível se os bloqueios de página tiverem sido desativados. A única maneira de desfragmentar sem bloqueios de página é bloquear toda a partição, o que não é possível para REORGANIZE, pois é apenas online.
Você precisa entender o que são um registro e uma página para avaliar o impacto de não permitir um determinado tipo de bloqueio. Se você não estiver familiarizado com os internos de armazenamento do SQL Server, comece com Anatomia de um registro e Anatomia de uma página . Simplificando:
Se você alterar os tipos de bloqueio permitidos:
Há dois cenários que conheço onde pode ser benéfico desabilitar um tipo de bloqueio. Não significa que não haja outros, espero que alguém dê exemplos.
Uma tabela de pesquisa acessada com frequência, que muda com pouca frequência - Ao desabilitar os bloqueios de nível de página e linha, todos os leitores terão um bloqueio de tabela compartilhada. Isso é mais rápido/mais barato do que o compartilhamento de intenção usual na tabela, seguido pelo compartilhamento de intenção em uma página e, finalmente, um bloqueio compartilhado em uma linha ou linhas específicas.
Evitando um cenário de bloqueio específico - Se você encontrar bloqueios causados por processos simultâneos que adquirem bloqueios que estão frequentemente na mesma página, não permitir bloqueios de linha resulta em bloqueios de página sendo executados. Apenas um processo pode acessar a página por vez, o outro deve esperar.
O primeiro exemplo é a micro-otimização e é improvável que produza benefícios mensuráveis em um sistema típico. O segundo resolverá esse cenário de impasse específico, mas pode introduzir efeitos colaterais inesperados, por exemplo, eliminar a simultaneidade em uma seção diferente do código. Difícil avaliar totalmente o impacto, aproxime-se com cautela!
O padrão é que ambos estejam ativados e isso não deve ser alterado sem um bom motivo.
Provavelmente nada. Tenho certeza que MS sabe melhor do que você ou eu
Já trabalhei em sistemas OLTP de alto volume e nunca senti necessidade de alterar as configurações. Um impasse deve ser repetido porque eles acontecerão de qualquer maneira
Citando do blog do SQL Server Storage Engine, "Lock Escalation in SQL2005" n que vale a pena ler completamente de qualquer maneira.
Eu acho que se você forçar apenas rowlocks, você consumirá recursos que poderiam ser usados de forma mais eficaz em outro lugar. Se sua carga é alta o suficiente para ser importante, então por que consumir memória? O artigo do blog vai para este
Eu suspeito que haja alguma superstição por trás disso, como estas: