J'ai utilisé ALTER INDEX REBUILD pour supprimer la fragmentation d'index. Dans certains cas, REBUILD ne semble pas supprimer cette fragmentation. Quelles sont les raisons pour lesquelles REBUILD ne supprime pas la fragmentation? Il semble que cela se produise surtout avec de petits indices.
Réponses:
Si un index est très petit (je crois moins de 8 pages), il utilisera des extensions mixtes. Par conséquent, il semblera qu'il reste encore une fragmentation, car l'étendue du boîtier contiendra des pages provenant de plusieurs index.
De ce fait, et également du fait que dans un index si petit que la fragmentation est généralement négligeable, vous ne devriez vraiment reconstruire des index qu'avec un certain seuil de page. Il est recommandé de reconstruire des index fragmentés d'au moins 1 000 pages .
Cela peut également se produire avec des index très LARGES.
J'avais quelques index sur une table avec environ 700m de lignes que je ne pouvais pas défragmenter en dessous d'environ 30%. Le problème n'était pas suffisamment d'espace libre contigu à l'intérieur de la base de données pour organiser l'index consécutivement.
Pour contourner un index très volumineux qui ne défragmentera pas, la meilleure solution consiste à pré-dimensionner une nouvelle base de données et à déplacer tous vos objets vers cette base de données, puis à recréer vos index là-bas.
J'ai eu du mal avec cela pendant un certain temps et comme JNK, je pensais que le problème était la persistance de l'espace libre et de la fragmentation physique sur le disque. Cependant, que faites-vous à ce sujet sur un SAN SSD?
J'ai maintenant découvert qu'il peut être judicieux d'inclure uniquement index_level = 0. C'est ainsi que cela se fait dans le script d'Ola Hallengren.
Une autre amélioration est de faire
REBUILD With (maxdop = 1)De cette façon, vous garantissez une amélioration maximale.