É possível desabilitar todos os bloqueios de uma tabela específica em qualquer versão do SQL Server?
Eu tenho um punhado de tabelas que são preenchidas com dados no momento da implantação. Por exemplo, uma das tabelas menores, [items].[Colour], contém 'Blue', 'Green', 'Red', 'White'. Após a implantação, o(s) aplicativo(s) sempre seleciona(m) dessas tabelas (nunca insere, atualiza ou exclui). Eu comecei a pensar, se essas tabelas são apenas lidas, então qual é o sentido de ter bloqueios? Suponho que demore algum tempo para obter um bloqueio. Mesmo que essa quantidade de tempo seja insignificante, parte de mim não ficará satisfeita até que eu mesmo teste a diferença.
Enquanto procurava a resposta por conta própria, descobri que posso marcar um banco de dados inteiro como somente leitura e que pode haver alguns benefícios . Eu quero esses benefícios, mas numa base de tabela por tabela. Eu também li sobre desabilitar o escalonamento de bloqueio, mas se eu entendi a documentação corretamente, isso só levaria a mais bloqueios (embora mais refinados), que é o oposto do que eu quero alcançar.
Eu sei que posso atualizar cada consulta que usa a tabela para ter uma NOLOCKdica, mas isso apresenta um problema secundário. No futuro, quando eu ensinar meu aplicativo a aprender novos Colours em tempo de execução, quero atualizar todas as consultas que usam a tabela para remover a NOLOCKdica? Isso soa como um incômodo.
Parece que a pergunta está recebendo alguns votos negativos e, sem nenhuma explicação fornecida, vou assumir que é porque isso parece que o que estou pedindo é otimização prematura. A otimização prematura é, como apontado em um comentário agora excluído, a raiz de todo mal. Eu sei disso e não estou otimizando prematuramente. Aqui está o porquê.
Tenho permissão para pesquisar essa API uma vez por segundo. Não está declarado na página vinculada, mas vi a regra em algum lugar (confie em mim). De qualquer forma, meu aplicativo leva de 100ms a 800ms para fazer a solicitação HTTP, baixar o arquivo de texto gzip'd e descompactá-lo. A maior parte desse tempo é gasto aguardando a resposta da API. Isso me deixa quase sem tempo para processar todos os dados em tabelas de banco de dados bonitas, organizadas e normalizadas. Para ser competitivo, tenho que processar todos os dados em 200 ms ou menos. Estou tão perto de atingir meu objetivo que estou cortando custos descartando dados que talvez não precise, enviando todos os dados para o banco de dados de uma só vez em um grande e feio pacote etc. Então, sim, estou otimizando, mas não prematuramente (na minha opinião).
Também reconheço que o que estou pedindo pode não trazer benefícios de desempenho. Na verdade, a única solução que foi fornecida até agora não pareceu afetar o desempenho em nada. Eu não poderia saber disso antes de fazer a pergunta, e agora quaisquer futuros visitantes que estejam se perguntando se isso os ajudará podem ver o teste que realizei e saber que não vale a pena. Isso não é útil?
Se isso não resolver as preocupações dos downvoters, por favor, considere deixar um comentário com o que você acha que eu poderia melhorar sobre a pergunta.
Você pode definir grupos de arquivos individuais como somente leitura, mas, a menos que as versões recentes do servidor SQL tenham alterado os mestres, isso não conferirá o benefício de bloqueio reduzido encontrado ao definir um banco de dados inteiro como somente leitura.
Você pode tentar manter a configuração somente leitura em um banco de dados separado e usar consultas entre bancos de dados para acessá-la. Use sinônimos para poder fazer referência a esses objetos como se ainda fossem tabelas locais. De cabeça, não posso dizer se isso se comportaria como desejado (bloqueio reduzido) ou se o planejador/executor de consultas acabaria tratando o arranjo da mesma forma como se tivesse apenas um grupo de arquivos somente leitura, mas pode vale a pena testar como uma opção. Se funcionar, para migrar o objeto de volta para o banco de dados normal, simplesmente copie os dados para uma nova tabela e atualize o sinônimo, ou faça o sinônimo completamente e dê à tabela esse nome diretamente (sugiro o último se esta for a única instância desse banco de dados, o primeiro se você tiver muitos que podem estar em versões diferentes em um determinado momento,
OBSERVAÇÃO: (como apontado por Rainbolt nos comentários abaixo) usar um acesso entre bancos de dados como esse impedirá que você defina restrições de chave estrangeira, portanto, mesmo que isso conferisse um benefício de desempenho das diferenças de bloqueio, ainda não seria recomendado. Portanto, tome a resposta acima como "tecnicamente você poderia" em vez de um bom conselho! Você pode implementar a restrição de uma maneira com uma restrição de verificação ou acionar em todos os lugares em que normalmente teria a restrição FK, mas isso é um trabalho extra para manter/depurar e aplicar de outra maneira (não deixar uma linha ser excluída do objeto referido se for referenciado por linhas em outro lugar) não é possível.