Pourquoi ne pas reconstruire des index avec un nombre de pages <1000?

J'utilise le script Ola Hallengrens pour la maintenance de l'index. Avant cela, j'ai utilisé la requête suivante pour voir quels index sont les plus fragmentés:

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

Dans mon cas, l'avg_fragmentation était supérieure à 70% pour 15 index et supérieure à 30% pour 28 index.

Donc, je reconstruis chaque index en utilisant la solution d'Ola Hallengren. Lorsque j'ai relancé la requête, voici le résultat:

Fragmentation supérieure à 70% pour 12 index, supérieure à 30% pour 15 index.

Je me suis dit que la raison était à cause de la page_count, qui était inférieure à 1000 pour chacun des index qui étaient encore très fragmentés. Par exemple, l'un des indices avec un page_count de 967 a un pourcentage de fragmentation de 98,98% ! Il me semble qu'il vaut la peine de reconstruire cet index! Je l'ai fait, et après, la fragmentation était de 0% . De plus, un indice avec un page_countde 132 est passé de 95% à 0%

Donc, ma question est, quelles raisons y aurait-il pour NE PAS reconstruire ces index? Une raison pourrait être que la reconstruction coûte du temps et des ressources, mais parce que les index sont petits, cela ne signifie-t-il pas que cela coûte relativement peu de ressources et qu'il serait quand même bénéfique de la reconstruire de toute façon?

Il y a plusieurs questions liées sur ce site, mais toutes répondent à la question de savoir pourquoi un index ne défragmenterait pas, ou si les index sont toujours utiles s'ils sont petits et que vous ne les défragmentez pas, alors qu'ici, la déclaration diminue la fragmentation, avec la question étant, pourquoi ne pas le faire de toute façon?

Les indications concernant le nombre minimum de pages sont quelque peu arbitraires . Les principaux avantages de la réduction de la fragmentation sont les suivants:

1. Il peut améliorer les performances de lecture anticipée pour les numérisations à grande échelle; et
2. Cela peut améliorer la densité de la page (nombre de lignes par page)

Par définition, ces deux facteurs sont moins importants pour les petits indices.

Le contre-argument de la reconstruction de petits index est essentiellement:

"Pourquoi s'embêter? N'as-tu pas des choses plus importantes à t'inquiéter?".

Cela dit, la reconstruction / réorganisation n'est pas gratuite. Il peut être utile d'éviter l'effort supplémentaire et la génération de journaux dans certains cas (par exemple, si le journal est expédié / copié sur un WAN pour un certain nombre de raisons possibles - mise en miroir, groupes de disponibilité, réplication ...). De plus, à moins que (ou même si, dans certains cas) vous ne reconstruisiez en ligne, la reconstruction peut avoir un impact sur d'autres processus simultanés via le verrouillage. Enfin, pour les petits index, la reconstruction peut même ne pas réduire la fragmentation de toute façon, en raison d'allocations d'étendues mixtes (sauf si vous exécutez avec l' indicateur de trace 1118 activé).

Si vous vous sentez toujours plus heureux de reconstruire ces petits index et que cela ne vous dérange pas, changez certainement la valeur du @PageCountLevelparamètre passé à la procédure d'Ola.

Voir l' enregistrement PASS TV de la présentation de Paul Randal sur la fragmentation d'index pour tous les détails.

Vous aimerez peut-être aussi regarder Brent Ozar parler de la raison pour laquelle la fragmentation d'index n'a pas d'importance dans SQL Server.