Como as instruções SELECT usam um bloqueio compartilhado em contraste X e U, parece-me que usar WITH(TABLOCK) em consultas de estilo de datawarehouse usadas para relatórios é a coisa correta a fazer para evitar o gerenciamento de bloqueios e o escalonamento de bloqueios.
Estou falando de casos em que os dados não são dados de produção ao vivo e a simultaneidade não é um problema. Por exemplo, eu não me importo em bloquear escritores usando um bloqueio de tabela compartilhada. É claro que não quero bloquear leitores, mas os bloqueios S não bloqueiam outros leitores.
Então, acho que posso formular minha pergunta como: Em um ambiente de data warehouse, todas as consultas não devem ser sugeridas com WITH (TABLOCK)? E, teoricamente, isso deve melhorar o desempenho. Se não, por quê?
Obrigado
Se você estiver preocupado com a obtenção de bloqueios, considere usar o isolamento de instantâneo de leitura confirmada ou o isolamento de instantâneo . Eles usam versionamento de linha em vez de bloqueios compartilhados durante a leitura. Se houver poucas alterações no banco de dados, há poucas razões para preferir sua solução.
Por fim, se o banco de dados for completamente imutável, ele poderá ser definido como somente leitura. Nesse caso, o SQL Server não fará nenhum bloqueio, independentemente do nível de isolamento solicitado. Há outras coisas a serem consideradas, como criar estatísticas, antes de definir um banco de dados como somente leitura. Consulte a documentação para obter mais detalhes.
Adicionar dicas de bloqueio de tabela a cada consulta é tecnicamente plausível, mas duvido que seja a solução ideal em muitos casos. Você teria que fazer muitas mudanças se quisesse mudar seus arranjos.
Documentação: Guia de controle de versão de linha e bloqueio de transação
Se o seu único objetivo é minimizar o uso de recursos, sim - o uso de recursos será menor adquirindo bloqueios de tabela antecipadamente.
Uma opção pode ser configurar índices selecionados se você permitir bloqueios de linha e página neles. Desautorize ambos e você obterá bloqueios de mesa antecipadamente. Mas é claro que isso será para todos os usuários por meio desse índice - talvez não seja o que você deseja.
Agora, quanto você ganha? Você me diz. O que você está pedindo quanto custa 5000 fechaduras. (O escalonamento de bloqueio pode acontecer em algum outro número, 5000 não é definitivo, mas é um número bastante frequente e pode servir como exemplo.) Execute um rastreamento e capture o custo em que em um caso você obtém 1 bloqueio e o outro recebe 5000 fechaduras. Mantenha a mesa o mais pequena possível, senão a diferença provavelmente se perderá no barulho.
Você pode argumentar que o escalonamento pode falhar e continuará adquirindo bloqueios de linha (portanto, devemos usar um número muito maior que 5000). Mas, nesse caso, você tem um conflito e, se não permitir bloqueios de granularidade menores, o resultado será uma situação de bloqueio, que é muito pior do que os poucos ciclos de CPU e uso de memória que 5000 bloqueios custam.
Acho que vale a pena testar as dicas de consulta em diferentes situações, mas raramente são uma garantia de sempre ser a escolha certa para uma determinada situação (caso contrário, a Microsoft esperançosamente tornaria esse o comportamento padrão de tal situação).
Se você acredita que pode ver melhorias ao usar a
TABLOCKdica em algumas de suas consultas de data warehouse, experimente-a em algumas, meça os resultados e compare-os com suas consultas sem ela. Você pode surpreendentemente encontrar quase nenhuma diferença e, nesse caso, eu pessoalmente adiaria o comportamento padrão de não usá-lo.Para responder às suas perguntas, sim, se você sabe que uma consulta sempre será escalada para um bloqueio de tabela, provavelmente é melhor usar a
TABLOCKdica antecipadamente para evitar a escalação e, pelo menos, melhorar minimamente o desempenho. Mas nem todas as consultas de data warehouse resultam necessariamente em escalação para um bloqueio de tabela, portanto, você pode prejudicar o desempenho usando prematuramente aTABLOCKdica nesse caso.Como acontece com a maioria das coisas relacionadas ao desempenho do banco de dados, a melhor maneira de descobrir seus casos de uso específicos é testar.