Estou procurando uma opinião, que sei que geralmente é desaprovada, então peço desculpas antecipadamente.
Atualmente, estou em um ambiente em que todas as instâncias são SQL Server Enterprise Edition. As tarefas de manutenção estão sendo executadas por um plano personalizado. Este plano, por padrão, faz uma reconstrução offline durante a noite.
Não há janelas de manutenção noturna e, como o ambiente é multinacional, nem sempre a parte "noturna" da manutenção significa o ponto de menor atividade (no entanto, significa em 95% dos casos). E há muitos trabalhos noturnos que estão lentos devido, em parte, à manutenção agressiva da indexação. (Uma consulta de relatório que ficou presa esperando a reconstrução do índice de uma tabela de 300 GB com dados do cliente me levou a esse caminho)
Posso assumir que o seguinte terá um impacto principalmente positivo:
- Adicione um valor mínimo de fragmentação de 10% para reorganizar (atualmente feito todas as noites, independentemente de %)
- Alterando os requisitos mínimos de reconstrução para 30% (atualmente em 5%)
- Alterando o comportamento padrão para ONLINE
- Alterando a contagem mínima de páginas para 1.000 (atualmente em 50)
Principalmente, o que estou perguntando aqui é se estou correto ao assumir que o cronograma de manutenção atual é muito agressivo. E que as 4 mudanças acima terão um efeito líquido positivo.
Estou mais preocupado em reorganizar tudo todas as noites para tudo... Isso parece excessivo.
Difícil para nós saber se será um líquido positivo. Estes são praticamente acéfalos:
Você ainda deve testá -los, no entanto.
Mas não temos ideia do impacto que a desfragmentação/reconstrução tem em sua carga de trabalho de leitura e se esperar até que algum % seja melhor, não ganhe nada ou talvez até piore algumas consultas de leitura.
Outras pessoas já aperfeiçoaram esse tipo de manutenção e tiraram você do jogo de adivinhação. Obtenha os scripts de Ola Hallengren ou nossa ferramenta, Fragmentation Manager . Você pode fazer alterações como está sugerindo simplesmente alterando os valores dos parâmetros. E não se esqueça de que essas pessoas já resolveram muitos bugs que você ainda não encontrou e pensaram em coisas que você ainda não pensou. E quando novas operações são oferecidas online em versões mais recentes, ou novas opções são adicionadas a diferentes recursos de manutenção, essas ferramentas e scripts serão atualizados para você. O que você fez é carinhosamente conhecido como reinventar a roda:
Recusar-se a mudar para uma solução mais automatizada por causa de investimentos no passado é como manter uma péssima governanta ou jardineiro porque você os pagou no ano passado. Às vezes você só precisa cortar o cordão.
Presumo que o banco de dados seja altamente transacional, para exigir reconstruções; e sendo internacional, acessado o tempo todo... então NA MINHA OPINIÃO deixe tudo como está, e mude para reconstruções ONLINE.
Tudo o tempo todo - é um desperdício; mas não um choque de trem. Facilite na tarefa uma verificação de fragmentação - definindo-a um pouco menos agressivamente - 10% fragmentado e depois reorganizado; 20%, em seguida, reconstruir.
Então você introduz apenas 2 mudanças, avalia e ajusta novamente. Dessa forma, você considera opcional em vez de TUDO O TEMPO TODO; e ONLINE para que você tenha acesso de pessoas.
Como sugerido, confira o trabalho de Ola Hallengren. Exemplo brilhante de codificação... inspirador.
Boa sorte!
As principais diferenças são:
A reconstrução do índice OFFLINE é mais rápida que a reconstrução ONLINE.
Espaço em disco extra necessário durante as reconstruções de índice online do SQL Server.
Bloqueios do SQL Server adquiridos com recriações de índice online do SQL Server.
Esse bloqueio de modificação de esquema bloqueia todos os outros acessos simultâneos à tabela, mas é mantido apenas por um período muito curto enquanto o índice antigo é descartado e as estatísticas atualizadas.