Por que não recriar índices com contagem de páginas <1000?

17

Eu uso o script Ola Hallengrens para manutenção do índice. Antes de fazer isso, usei a seguinte consulta para ver quais índices são mais fragmentados:

SELECT dbschemas.[name] as 'Schema',
dbtables.[name] as 'Table',
dbindexes.[name] as 'Index',
indexstats.avg_fragmentation_in_percent,
indexstats.page_count
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id]
INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id]
INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id]
AND indexstats.index_id = dbindexes.index_id
ORDER BY indexstats.avg_fragmentation_in_percent desc

No meu caso, a avg_fragmentation estava acima de 70% para 15 índices e acima de 30% para 28 índices.

Então, reconstruo todos os índices usando a solução de Ola Hallengren. Quando executei a consulta novamente, este foi o resultado:

Fragmentação acima de 70% para 12 índices, acima de 30% para 15 índices.

Achei que o motivo era o page_countmenor que 1000 para cada um dos índices ainda muito fragmentados. Por exemplo, um dos índices com um page_count de 967 tem uma porcentagem de fragmentação de 98,98% ! Para mim, parece valer a pena reconstruir esse índice! Eu fiz, e depois, a fragmentação foi de 0% . Além disso, um índice com page_count132 passou de 95% para 0%

Então, minha pergunta é: quais os motivos para NÃO reconstruir esses índices? Um motivo pode ser que a reconstrução custa tempo e recursos, mas como os índices são pequenos, isso não significa que custa relativamente poucos recursos e ainda assim seria benéfico reconstruí-lo de qualquer maneira?

Existem várias perguntas relacionadas neste site, mas todas respondem à pergunta por que um índice não desfragmentaria, ou se os índices ainda seriam úteis se fossem pequenos e você não os desfragmentasse, enquanto aqui a instrução diminui a fragmentação, com a questão é: por que não fazer assim mesmo?

user1261104
fonte
É provável que pequenos índices sejam armazenados em cache na memória. Os índices que não incorrem em IO de qualquer maneira não se beneficiam da desfragmentação. Esta regra de contagem de 1000 páginas é uma heurística.
usr

Respostas:

20

As orientações relativas ao número mínimo de páginas são um tanto arbitrárias . Os maiores benefícios da redução da fragmentação são:

  1. Pode melhorar o desempenho de leitura antecipada para varreduras de grande alcance; e
  2. Pode melhorar a densidade da página (número de linhas por página)

Esses dois fatores são menos importantes para pequenos índices, por definição.

O contra-argumento para reconstruir pequenos índices é essencialmente:

"Por que se preocupar? Você não tem coisas mais importantes com que se preocupar?".

Dito isto, a reconstrução / reorganização não é gratuita. Pode valer a pena evitar o esforço extra e a geração de log em alguns casos (por exemplo, se o log for enviado / copiado em uma WAN por qualquer número de razões possíveis - espelhamento, grupos de disponibilidade, replicação ...). Além disso, a menos que (ou mesmo se, em alguns casos) você esteja reconstruindo online, a reconstrução poderá afetar outros processos simultâneos através do bloqueio. Finalmente, para índices pequenos, a reconstrução pode nem reduzir a fragmentação, devido a alocações de extensões mistas (a menos que você esteja executando com o sinalizador de rastreamento 1118 ativado).

Se você ainda se sente mais feliz ao reconstruir esses pequenos índices e não se importa com as consequências, altere de qualquer maneira o valor do @PageCountLevelparâmetro passado ao procedimento de Ola.

Veja a gravação do PASS TV da apresentação de Paul Randal na fragmentação do índice para obter todos os detalhes.

Talvez você também goste de assistir Brent Ozar falar sobre Por que a fragmentação de índice não importa no SQL Server.

Paul White restabelece Monica
fonte