web-dev-qa-db-fra.com

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 de faire 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 à % 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 sur 70% pour 12 index, sur % pour 15 index.

Je me suis dit que la raison était à cause du page_count, qui était inférieur à 1 000 pour chacun des indices encore très fragmentés. Par exemple, l'un des index avec un page_count sur 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 %. En outre, un index avec un page_count sur 132 est passé de 95% à %

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?

sql-serverindexmaintenance
19
user1261104

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 analyses à grande plage ; 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'avez-vous pas des choses plus importantes à vous soucier?".

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 (ou même si, dans certains cas) que vous reconstruisez 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 des allocations à partir d'étendues mixtes (sauf si vous exécutez avec indicateur de trace 1118 activé).

Si vous vous sentez encore plus heureux de reconstruire ces petits index, et que cela ne vous dérange pas, modifiez la valeur de @PageCountLevel paramètre passé à la procédure d'Ola.

Voir le 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 Pourquoi la fragmentation d'index n'a pas d'importance dans SQL Server.

21
Paul White 9