O tempo necessário para a reconstrução do índice depende do nível de fragmentação?
A reconstrução de um índice fragmentado de 80% leva aproximadamente 2 minutos se a reconstrução do mesmo índice fragmentado 40% leva 1 minuto?
Estou solicitando o RUNTIME (por exemplo, em segundos) que pode ser necessário para executar a ação necessária, e não sobre qual ação é necessária em que situação específica. Estou ciente das práticas recomendadas básicas quando o reorganização do índice ou atualizações de reconstrução / estatística devem ser feitas.
Esta pergunta NÃO faz perguntas sobre o REORG e a diferença entre REORG e REBUILD.
Antecedentes: devido à configuração de diferentes trabalhos de manutenção de índice (todas as noites, trabalho mais pesado nos finais de semana ...), eu me perguntava se um trabalho de manutenção de índice OFF-LINE diário "leve a intenso" deveria ser melhor executado em índices fragmentados de média baixa para manter o fora do horário de trabalho pequeno - ou isso não importa e a reconstrução em um índice fragmentado de 80% pode demorar o mesmo tempo de folga que a mesma operação no mesmo índice fragmentado de 40%.
Segui as sugestões e tentei descobrir o que estava acontecendo. Minha configuração experimental: em um servidor de teste que não faz mais nada e não está sendo usado por ninguém, criei uma tabela com um Índice de Cluster em uma coluna de chave primária de identificador exclusivo com algumas colunas adicionais e tipos de dados diferentes [2 numéricos, 9 datetime e 2 varchar (1000)] e simplesmente adicionou linhas. Para o teste apresentado, adicionei cerca de 305.000 linhas.
Em seguida, usei um comando de atualização e atualizei aleatoriamente um intervalo de linhas filtrando um valor inteiro e alterei uma das colunas VarChar com um valor de sequência variável para criar fragmentação. Depois disso, verifiquei o avg_fragmentation_in_percentnível atual sys.dm_db_index_physical_stats. Sempre que criei uma "nova" fragmentação para o meu benchmark, adicionei esse valor incluindo o physical_page_countvalor para minhas gravações do qual é feito o diagrama a seguir.
Então eu corri: Alter index ... Rebuild with (online=on);
e peguei CPU timeusando STATISTICS TIME ONminhas gravações.
Minhas expectativas: esperava ver pelo menos a indicação de um tipo de curva linear que mostrasse uma dependência entre o nível de fragmentação e o tempo da CPU.
Este não é o caso. Não tenho certeza se esse procedimento é realmente apropriado para um bom resultado. Talvez o número de linhas / páginas seja muito baixo?
No entanto, os resultados indicam que a resposta à minha pergunta original definitivamente seria NÃO . Parece que o tempo de CPU necessário para o SQL Server reconstruir o índice não depende do nível de fragmentação nem da contagem de páginas do índice subjacente.
O primeiro gráfico mostra o tempo de CPU necessário para recompilar o índice em comparação com o nível de fragmentação anterior. Como você pode ver, a linha média é relativamente constante e não existe uma relação entre fragmentação e tempo de CPU necessário observável.
Para respeitar a possível influência da alteração do número de páginas no índice após minhas atualizações que podem exigir mais ou menos tempo para serem reconstruídas, calculei o NÍVEL DE FRAGMENTAÇÃO * CONTAGEM DE PÁGINAS e usei esse valor no segundo gráfico que mostra a relação do tempo de CPU necessário vs. fragmentação e contagem de páginas.
Como você pode ver, isso também não indica que o tempo necessário para reconstruir é influenciado pela fragmentação, mesmo que o número de páginas varie.
Depois de fazer essas declarações, acho que meu procedimento deve estar errado, porque o tempo de CPU necessário para reconstruir um índice enorme e altamente fragmentado pode ser influenciado apenas pelo número de linhas - e eu realmente não acredito nessa teoria.
Então, porque eu realmente e definitivamente quero descobrir isso agora, quaisquer outros comentários e recomendações são muito bem-vindos .
