Conveniência de usar STATISTICS_NORECOMPUTE


9

Recentemente, me envolvi na manutenção de um conjunto de bancos de dados com alguns problemas interessantes de índice. Uma das que mais me agrava são as diferenças nos índices entre desenvolvimento, teste, modelo e máquinas de produção. Como as diferenças dificultam as consultas de ajuste, é um dos meus primeiros projetos.

Ao comparar os ambientes de teste e modelo, observei que a maioria dos índices no ambiente de modelo foi STATISTICS_NORECOMPUTEconfigurada, ONenquanto aqueles em teste não. Em todos os ambientes, há um trabalho noturno que atualiza as estatísticas de todos os bancos de dados.

Eu nunca lidei STATISTICS_NORECOMPUTEantes, então aqui estão minhas perguntas. Existem práticas recomendadas ao lidar com essa configuração? Se estou fazendo atualizações de estatísticas no final do dia, é melhor entregar STATISTICS_NORECOMPUTEtodos os ambientes em todos os índices? Ou existe uma boa razão para não?

Edição: Eu encontrei um dos blogs de Kimberly Tripp sobre o assunto aqui que parece sugerir que STATISTICS_NORECOMPUTEdeve ser usado com moderação na melhor das hipóteses. Mas ainda estou preocupado em desativá-lo globalmente. Alguém já tentou isso e o que eles experimentaram?


Você precisaria ver este aplicativo para acreditar. Algumas tabelas possuem dezenas de índices, outras não, várias possuem duplicatas múltiplas. É uma verdadeira bagunça. Alguma orientação geral a seguir? Algum lugar onde eu possa ler?
Kenneth Fisher

11
Um bom caso seria usar STATISTICS_NORECOMPUTE = ON e FILLFACTOR = 100 para tabelas de pesquisa somente leitura que são alteradas apenas pelos DBAs usando um script que executa INDEX REBUILD com FULLSCAN após as alterações; então a tabela está em ótima forma com estatísticas ótimas e sem outras alterações, não há motivo para considerar a recálculo das estatísticas ou deixar espaço para reduzir as divisões de página em alterações futuras.
Anti-weakpasswords

Respostas:


4

É realmente uma coisa situacional que você deseja analisar por tabela ou por índice, e realmente precisa descobrir o que está em produção antes de executar qualquer ação. Em caso de dúvida, use o que está em produção em outros ambientes também, mesmo que isso signifique usar várias configurações malucas. Você simplesmente não pode ter uma boa idéia de como a produção se comportará se as coisas forem diferentes no teste ou no desenvolvedor.

De qualquer forma, a recomendação geral de deixar as estatísticas de atualização automática ativadas ( STATISTICS_NORECOMPUTE = OFFque é o padrão) é por motivos de segurança, porque se isso estiver desativado e nada estiver atualizando manualmente as estatísticas, o resultado pode ser um plano de execução realmente horrendo que nunca muda. depois de serem criados (e não serão invalidados por outros motivos posteriormente).

Você disse que as estatísticas de atualização automática estão desativadas para a maioria dos índices (acho que originalmente eu os interpretei errado como tudo , não na maioria ). Para os índices com estatísticas de atualização automática ainda ativados, essa configuração faz sentido, dada a atividade nessas tabelas? Eu esperaria que estas sejam tabelas de atividade mais alta. É possível que muito trabalho tenha sido feito para descobrir isso, e pode valer a pena manter (ou considerar fortemente) essas configurações. No mínimo, anote quais são essas estatísticas, porque essas informações podem ser úteis no futuro.

Pensando mais nisso, direi que a estratégia atual faz sentido. É melhor do que deixar as estatísticas de atualização automática ativadas para tudo? Parece que alguém pensou assim, a ponto de valer a pena a facilidade de gerenciamento de ter um trabalho associado ao SQL Agent.

Se a ideia era ter estatísticas novas disponíveis sem bloquear consultas (como essa ), considere ativar a atualização automática novamente para tudo e também ativar AUTO_UPDATE_STATISTICS_ASYNCtambém. Em seguida, provavelmente mude a programação do trabalho para executar uma vez por semana, em vez de diariamente, pois você ainda deseja que as estatísticas sejam atualizadas WITH FULLSCANperiodicamente.

No entanto, posso deixar de lado, já que você provavelmente tem peixes maiores para fritar se os próprios índices forem diferentes entre os ambientes e as reconstruções de estatísticas não forem muito dolorosas. O que há agora faz sentido; você só precisa tornar as coisas consistentes entre os ambientes. Provavelmente é marginalmente melhor do que as configurações mais simples que sugeri, à custa de mais trabalho sendo feito. Mas descubra o que está em produção, tenda a usá-lo e passe a coisas mais importantes; revisite isso quando você precisar ajustar com mais precisão o desempenho - as melhores estatísticas do mundo não salvarão uma consulta que está sem um índice crítico.


oops ... achei que optou por não enviar este comentário.
swasheck
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.