Tout d'abord, il est important de déterminer si la fragmentation est importante.
Si votre requête ne fait que des recherches sur une seule ligne, vous ne remarquerez peut-être pas du tout la fragmentation. Sur les SAN modernes, la mise en cache au niveau du SAN peut rendre les E / S phyiscales suffisamment rapides pour que la fragmentation n'ait pas d'importance. Sur SSD, le modèle d'E / S aléatoire provoqué par l'analyse d'un index fragmenté peut en fait entraîner de meilleures performances que les données non fragmentées.
Souvent, les utilisateurs remarquent que la reconstruction d'un index a résolu un problème de performances. La reconstruction d'un index génère également de nouvelles statistiques. Il se peut que le vrai correctif soit de nouvelles statistiques, et non la reconstruction de l'index. UPDATE STATISTICS...WITH FULLSCAN
peut être un moyen moins coûteux, plus rapide et moins intrusif de résoudre le même problème de performances.
Si vous ne rencontrez pas de problèmes causés par la fragmentation, vous pourriez dépenser beaucoup de temps et d'efforts sans gain réel.
Deuxièmement, il existe deux types de fragmentation:
Fragmentation physique. C'est ce à quoi la plupart des gens pensent lorsqu'ils pensent à la fragmentation. Les pages sont hors service et doivent être réorganisées. Lors de l' analyse d' un index, ce type de fragmentation peut parfois poser problème. J'ai généralement remarqué que cela avait le plus grand impact sur les performances des lectures physiques . Si vous regardez les résultats de sys.dm_db_index_physical_stats
, ce nombre est la avg_fragmentation_in_percent
colonne.
Fragmentation de faible densité. Cette fragmentation est causée par des pages qui ne sont que partiellement remplies de données. Vous avez une faible densité de données car vos données sont réparties sur plus de pages que nécessaire. Par conséquent, la lecture des données nécessite plus d'E / S car les données sont réparties sur plus de pages que nécessaire. Cela peut affecter les lectures logiques et physiques. Si vous regardez les résultats de sys.dm_db_index_physical_stats
, ce nombre est la avg_page_space_used_in_percent
colonne. Cette colonne n'est remplie que lors de l'utilisation du mode SAMPLED
ou DETAILED
.
Alors, que faites-vous à ce sujet:
Fragmentation physique : si vous recherchez simplement des chiffres élevés avg_fragmentation_in_percent
, pensez vraiment à ne pas perdre votre temps. Assurez-vous que votre requête ne fonctionne pas correctement et utilisez un environnement de test pour confirmer que vous résolvez un problème en éliminant la fragmentation.
Vous pouvez résoudre la fragmentation physique en faisant ALTER INDEX...REORGANIZE
. L' REORGANIZE
opération est en ligne, déplaçant les pages une à la fois pour les réorganiser dans l'ordre physique. Si vous tuez une REORGANIZE
instruction en cours de route, tout travail déjà effectué est conservé - seule la page en cours de déplacement sera restaurée. Faire une REORGANIZE
sur une grande table très fragmentée peut nécessiter plus d'espace total de journal des transactions et, en mode de récupération complète, peut générer une quantité importante de sauvegardes du journal des transactions. Cela peut également prendre plus de temps à REORGANIZE
un index très fragmenté qu'à REBUILD
lui.
Vous verrez souvent des conseils pour effectuer un REBUILD
sur des index hautement fragmentés, plutôt qu'un REORGANIZE
- C'est parce que la reconstruction à partir de zéro peut être plus efficace. Cependant, la réorganisation peut être une opération «plus en ligne» et est parfois préférée, même pour des index très fragmentés.
La fragmentation de faible densité ne peut pas être corrigée par REORGANIZE
. Il ne peut être corrigé qu'en faisant un ALTER INDEX...REBUILD
. En faisant l'index avec ONLINE=ON
, vous devriez pouvoir minimiser le blocage. Cependant, le REBUILD
doit encore prendre un verrou pendant un moment pour échanger l'ancien index pour le nouvel index. Sur un système très occupé, atteindre ce verrou exclusif peut parfois être un problème. Vous devriez être en mesure de confirmer si vous rencontrez ce problème en utilisant quelque chose comme sp_whoisactive pour examiner le blocage lors de votre reconstruction et en examinant les détails des verrous et des attentes. L'utilisation de l' WAIT_AT_LOW_PRIORITY
option peut être utile si vous savez qu'il y a une période de faible utilisation à venir et que votre reconstruction peut se «faufiler» pour ce swap lorsque l'activité baisse suffisamment pour atteindre ce verrou. Notez qu'un long termeREBUILD
l'opération va également être une transaction ouverte de longue durée. Les transactions ouvertes de longue durée peuvent avoir leurs propres problèmes, liés à l'utilisation / la réutilisation du journal des transactions. Si vous utilisez la mise en miroir ou des groupes de disponibilité, vous devez également tenir compte du rétablissement du journal des transactions sur le réplica secondaire.
REORGANIZE
réduira la fragmentation des pages foliaires et l'espace compact commeREBUILD
, juste moins efficacement. Êtes-vous sûr que la grande taille est due à la fragmentation? Quel est le facteur de remplissage?