O tempo de reconstrução do índice depende do nível de fragmentação?

8

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.

Estatísticas de fragmentação e reconstrução de CPU

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 .

Magier
fonte

Respostas:

2

O tempo necessário para a reconstrução do índice depende do nível de fragmentação?

Acredito que esse não será o principal parâmetro no qual o SQL Server decidirá e leva tempo para reconstruir \ reorganizar o índice:

Existem vários outros fatores envolvidos com base em "DADOS", através dos quais ele decide por quanto tempo levará: Parâmetros como

Fator 1: tamanho da tabela

Fator 2: Preocupações com disponibilidade

Fator 3: Particionamento

Fator 4: Colunas do Índice e Exclusividade

Se você quiser ler mais sobre esses fatores, pode consultar aqui .

Será que 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

Novamente, a resposta pode ser: depende! Para os números, você precisará testar o cenário e ver as saídas como ele vai. Acompanhe esses detalhes, como para o nível 80 da FRAG, a reconstrução levou X hrs \ mins \ segs e para o Frag nível 40, a reconstrução levou Y hrs \ mins \ segs. Calcule e retenha o histórico, digamos mais de 15 dias (depende da atividade de manutenção programada) e você poderá concluir quanto tempo realmente está demorando na comparação dos dois.

Além disso :

Você pode reunir os dados \ cálculo no progresso da reconstrução do índice:

usando DMV sys.dm_exec_requests OU

Se você tiver planos de Manutenção do Ola para Reindexação-Reorganização, existe uma opção para salvar o histórico das ações executadas durante a manutenção na tabela CommandLog, conforme explicado em Manutenção de Índice e Estatística do SQL Server . Depois que os dados são salvos, você pode consultar o tipo de comando `ALTER_INDEX - REBUILD 'e a diferença para o mesmo entre as colunas START TIME e END TIME

KASQLDBA
fonte
@KASQLDBA Entrei nas estatísticas / log da tabela CommandLog da Ola. A duração é muito, muito aleatória e não há relação com o nível de fragmentação reconhecível. Como eu tenho esses valores apenas em um ambiente de produção, o tempo necessário para reconstruir pode ser muito influenciado por outros processos, portanto isso parece não fornecer uma resposta geral.
Magier
8

Para todos os interessados, criei um gráfico mostrando a duração do índice REBUILD de cerca de 2500 reconstruções de índice em algumas semanas em relação à fragmentação do índice e seu tamanho em páginas.

Esses dados são baseados em 10 servidores SQL, centenas de tabelas e nos procedimentos de otimização de Ola Hallengren . O limite geral para reconstrução é definido como 5% de fragmentação.

Cortei algumas das maiores tabelas (10 Mi + Pages) nessas estatísticas para torná-las mais legíveis.

O gráfico mostra o tempo necessário (duração) como tamanho das bolhas. Os valores da maior bolha são de cerca de 220 segundos. Isso mostra que o tempo necessário para reconstruir um índice não está realmente relacionado à fragmentação. Em vez disso, parece depender mais do número de páginas que o índice possui. Também indica que a fragmentação de baixo nível consome mais tempo que a fragmentação mais alta. Duração da reconstrução do índice

O segundo gráfico é ampliado apenas na área <= 200 K páginas. Mostra o mesmo, leva mais tempo para índices maiores, não para mais fragmentação. insira a descrição da imagem aqui

Magier
fonte
6

REBUILDdo índice não depende da fragmentação. Ele descarta o índice completamente e o cria do zero.

REORGANZE índice - é para reduzir a fragmentação sem reconstruir o índice, portanto, não solte e crie.

A MS recomenda o uso de Reorganizar para fragmentação de 30% ou menos. Para maior fragmentação, é preferível reconstruir.

Aqui está o artigo do MSDN sobre isso: Reorganizando e reconstruindo índices

ATUALIZAR

Em termos de tempo necessário para concluir a operação, obviamente depende da fragmentação do índice. A reconstrução de um índice extremamente fragmentado levará menos tempo do que a reorganização; reconstruir um índice ligeiramente fragmentado levará muito mais tempo. Eu sugeriria tomar as diretrizes da Microsoft como ponto de partida e executar alguns testes em suas tabelas. O ponto de equilíbrio em termos de% de fragmentação dependerá da tabela específica, tamanho do índice e tipo de dados.

Stoleg
fonte
4

A reconstrução de um índice fragmentado de 80% leva aproximadamente 2 minutos se a reconstrução do mesmo índice fragmentado de 40% leva 1 minuto?

O algoritmo para um REBUILD vs REORG é diferente. Um REORG NÃO alocará novas extensões em oposição a um RECONSTRUÍDO. Um REORG funcionará com as páginas alocadas atualmente (aloca uma página aleatória de 8 KB para que possa mover as páginas) e as move e depois desalocam as páginas, se necessário.

Das minhas anotações internas do SQLSkills (anteriormente IE0) ...

Para RECONSTRUIR:

  • Ele pode usar várias CPUs - pode alavancar o paralelismo para fazer o trabalho rapidamente.
  • Para índices fortemente fragmentados (por exemplo, 80% como no seu exemplo), um REBUILD será muito mais rápido que um REORG. O REBUILD criará apenas outra cópia do índice, e o REORG ficará atolado na remoção da fragmentação e, portanto, será mais lento. Essa é a razão pela qual Paul Randal deu sua recomendação geral de que seria bom fazer uma REBUILD de um índice fortemente fragmentado.
  • Um REBUILD permitirá que você altere o modo de recuperação para BULK_LOGGED para um registro mínimo nesse local, gerando menos registros de log .

Para o índice REORG:

  • É sempre com rosca única. Sem paralelismo.
  • É mais lento para índices fortemente fragmentados e mais rápido para índices levemente fragmentados. O custo da criação de um índice versus a reorganização de um índice levemente fragmentado é maior e, portanto, um REORG será mais rápido para o índice levemente fragmentado.
  • Um REORG é sempre uma operação totalmente registrada.

Leia - Notas - Fragmentação, tipos e soluções de índice do SQL Server

Kin Shah
fonte
Kin, TY pelo seu comentário, mas acho que você supervisionou o núcleo da minha pergunta. Você está comparando reorg vs reconstruir. Eu perguntei sobre uma comparação entre reconstruir e reconstruir para diferentes níveis de fragmentação (ceteris paribus).
Magier
@ Magier, se você reler cuidadosamente minha resposta, ela responderá à sua pergunta principal - se um índice estiver muito fragmentado, reconstrua-o. O custo de reconstruir um fragmento levemente superior é muito mais do que reorganizar. Além disso, não há uma maneira certa ou errada de lidar com a fragmentação, reconstruindo ou reorganizando, tudo depende da disponibilidade do sistema, dados, tamanho do índice, subsistema de E / S de disco, etc. Além disso, você pode facilmente executar alguns testes conforme o seu ambiente comparar reconstruir vs. reconstruir para diferentes níveis de fragmentação. Você não pode?
Kin Shah
Eu nunca perguntei ou mencionei sobre o REORG. É tudo sobre RECONSTRUÇÃO. E, sim, com certeza eu poderia configurar testes e tentar criar níveis específicos de fragmentação para descobrir quanto tempo levará a reconstrução, mas eu queria ver se alguém já sabe e pode me dizer os resultados esperados dessa abordagem.
Magier
3

Eu sei que é um tópico antigo, mas acho que será benéfico compartilhar o post de Paul Randal aqui.

Velocidade do algoritmo

Uma reconstrução de índice sempre criará um novo índice, mesmo se não houver fragmentação. O período de tempo que a reconstrução leva está relacionado ao tamanho do índice, não à quantidade de fragmentação nele.

https://www.sqlskills.com/blogs/paul/sqlskills-sql101-rebuild-vs-reorganize/

Elvin Ahmadov
fonte
0

Sim, porque geralmente uma reconstrução precisa varrer o índice original em ordem ao transmitir as linhas (em ordem) para uma nova partição de índice físico. A fragmentação afeta as verificações não armazenadas em cache; portanto, a reconstrução levará mais tempo.

Quanto tempo mais depende da fragmentação e de como a CPU vincula todo o processo. A serialização de linhas consome bastante CPU e, portanto, pode não ter importância. Ou você pode obter taxas aleatórias de E / S de 1,5 MB / s, o que é facilmente 5 a 10 vezes mais lento do que uma reconstrução rápida (depende do esquema e dos dados). Dependendo das premissas que você faz, você provavelmente pode inventar algo entre 1x e 100x de desaceleração.

A reconstrução de um índice fragmentado de 80% leva aproximadamente 2 minutos se a reconstrução do mesmo índice fragmentado de 40% leva 1 minuto?

Não é uma relação linear. A métrica fragmentação é um muito procuração áspera por quanto tempo que leva para fazer a varredura de uma partição.

usr
fonte
@ Magier boa pesquisa. O tempo da CPU nunca é afetado pela fragmentação. Você está testando pequenas tabelas totalmente armazenadas em cache na memória, para que não haja E / S de leitura. O teste é inválido. Teste com tabelas maiores (como 100 MB) e faça CHECKPOINT; DBCC DROPCLEANBUFFERSantes de cada teste. Também estou interessado em ver os resultados. Certa vez, fiz um teste semelhante em que medi a velocidade da digitalização, dependendo da fragmentação, mas não me lembro do resultado.
usr
Lembre-se também de que o número de fragmentação é um indicador frouxo, porque o que realmente conta é o movimento físico da cabeça do disco. Posso imaginar muitos padrões de E / S razoavelmente rápidos, mas com 100% de fragmentação, conforme medido pelo SQL Server, usando sua definição restrita. Por exemplo, o padrão de alocação 1_2_3_4 onde 1-4 é varrido e _ é um furo deve ser rápido.
usr
que valor exatamente eu tenho que olhar então? Na verdade, recebo as seguintes informações do Rebuild: Tempo da CPU = 0 ms, tempo decorrido = 70 ms. Tabela 'tFrag2'. Contagem de varredura 4, leituras lógicas 512067, leituras físicas 26, leituras de leitura antecipada 71209, leituras lógicas de lob 0, leituras físicas de lob 0, leituras de leitura antecipada de 0. Tempos de Execução do SQL Server: Tempo de CPU = 8657 ms, tempo decorrido = 27246 em. Tempos de execução do SQL Server: tempo de CPU = 8657 ms, tempo decorrido = 27386 ms.
Magier
Esses horários são de três consultas? É um pouco confuso. Você pode dizer pelos primeiros números que muitos dados estão armazenados em cache. Também 70ms é muito curto para uma referência válida. Você pode esclarecer o que esses números representam?
usr
Os horários que mencionei vieram de STATISTICS_TIME e STATISTICS_IO. Vou reiniciar uma nova referência agora e, desta vez, quero obter resultados adequados. Portanto, quaisquer sugestões adicionais são bem-vindas. Não entendo o que a limpeza do cache de dados ajuda, pois tenho interesse em recuperar os dados rapidamente, mas na reconstrução do índice, o que, afinal, deve ser feito no disco?
Magier