Le temps requis pour la reconstruction d'index dépend-il du niveau de fragmentation?
La reconstruction d'un index fragmenté à 80% prend-elle environ 2 minutes si la reconstruction du même index fragmenté à 40% prend 1 minute?
Je demande le RUNTIME (par exemple en secondes) qui peut être nécessaire pour effectuer l'action requise, et non pas quelle action est requise dans quelle situation particulière. Je connais les meilleures pratiques de base lorsque la réorganisation d'index ou la reconstruction / les mises à jour de statistiques doivent être effectuées.
Cette question ne concerne PAS REORG et la différence entre REORG et REBUILD.
Le contexte: en raison de la configuration de différents travaux de maintenance d'index (chaque nuit, un travail plus lourd le week-end ...), je me demandais si un travail de maintenance d'index OFFLINE quotidien "léger intense" devrait être mieux effectué sur des index fragmentés bas-milieu pour garder le les temps d'arrêt sont petits - ou cela n'a même pas d'importance et la reconstruction sur un index fragmenté à 80% peut prendre le même temps d'arrêt que la même opération sur le même index fragmenté à 40%.
J'ai suivi les suggestions et j'ai essayé de découvrir moi-même ce qui se passait. Ma configuration expérimentale: sur un serveur de test ne faisant RIEN d'autre et n'étant utilisé par personne ou quoi que ce soit d'autre, j'ai créé une table avec un index clusterisé sur une colonne de clé primaire uniqueidentifier avec quelques colonnes supplémentaires et différents types de données [2 chiffres, 9 datetime, et 2 varchar (1000)] et simplement ajouté des lignes. Pour le test présenté, j'ai ajouté environ 305 000 lignes.
Ensuite, j'ai utilisé une commande de mise à jour et mis à jour au hasard une plage de lignes filtrant sur une valeur entière et changé l'une des colonnes VarChar avec une valeur de chaîne changeante pour créer une fragmentation. Après cela, j'ai vérifié le avg_fragmentation_in_percentniveau actuel sys.dm_db_index_physical_stats. Chaque fois que j'ai créé une "nouvelle" fragmentation pour mon benchmark, j'ai ajouté cette valeur, y compris la physical_page_countvaleur à mes enregistrements, le diagramme suivant est fait.
Ensuite, j'ai couru: Alter index ... Rebuild with (online=on);
et saisi le CPU timeen utilisant STATISTICS TIME ONdans mes enregistrements.
Mes attentes: je m'attendais à voir au moins l'indication d'une sorte de courbe linéaire qui montre une dépendance entre le niveau de fragmentation et le temps CPU.
Ce n'est pas le cas. Je ne sais pas si cette procédure est vraiment appropriée pour un bon résultat. Peut-être que le nombre de lignes / pages est trop faible?
Cependant, les résultats indiquent que la réponse à ma question d'origine serait certainement NON . Il semble que le temps processeur requis par SQL Server pour reconstruire l'index ne dépend ni du niveau de fragmentation ni du nombre de pages de l'index sous-jacent.
Le premier graphique montre le temps processeur nécessaire pour RECONSTRUIRE l'indice par rapport au niveau de fragmentation précédent. Comme vous pouvez le voir, la ligne moyenne est relativement constante et il n'y a pas du tout de relation entre la fragmentation et le temps de processeur requis observable.
Pour respecter l'influence possible du nombre de pages changeant dans l'index après mes mises à jour qui pourraient nécessiter plus ou moins de temps pour reconstruire, j'ai calculé LE NIVEAU DE FRAGMENTATION * LE COMPTE DES PAGES et j'ai utilisé cette valeur dans le deuxième graphique qui montre la relation entre le temps processeur requis vs fragmentation et nombre de pages.
Comme vous pouvez le voir, cela n'indique pas non plus que le temps requis pour reconstruire est influencé par la fragmentation même si le nombre de pages varie.
Après avoir fait ces déclarations, je suppose que ma procédure doit être erronée car le temps de processeur requis pour reconstruire un index énorme et très fragmenté ne peut alors être influencé que par le nombre de lignes - et je ne crois pas vraiment à cette théorie.
Donc, parce que je veux vraiment et définitivement le découvrir maintenant, tout autre commentaire et recommandation est le bienvenu .
Pour toutes les personnes intéressées, j'ai créé un graphique montrant la durée de RECONSTRUCTION de l'index d'environ 2500 reconstructions d'index en quelques semaines en relation avec la fragmentation de l'index et sa taille en pages.
Ces données sont basées sur 10 serveurs SQL, des centaines de tables et sur les procédures d'optimisation d'Ola Hallengren . Le seuil général de reconstruction est fixé à 5% de fragmentation.
J'ai coupé certains des plus grands tableaux (10 Mi + Pages) dans ces statistiques pour le rendre plus lisible.
Le graphique montre le temps requis (durée) en tant que taille des bulles. Les valeurs de la plus grande bulle sont d'environ 220 secondes. Cela montre que le temps requis pour reconstruire un index n'est pas vraiment lié à la fragmentation. Au lieu de cela, il semble être plus dépendant du nombre de pages de l'index. Cela indique également que la fragmentation de bas niveau prend plus de temps que la fragmentation plus élevée.
Le deuxième graphique est juste zoomé dans la zone <= 200 K Pages. Il montre la même chose, cela prend plus de temps pour les index plus grands, pas pour plus de fragmentation.
la source
REBUILDde l'indice ne dépend pas de la fragmentation. Il supprime entièrement l'index et le crée à partir de zéro.REORGANZEindex - sert à réduire la fragmentation sans reconstruction d'index, donc pas de suppression et de création.MS conseille d'utiliser Reorganize pour une fragmentation de 30% ou moins. Pour une fragmentation plus élevée, la reconstruction est préférable.
Voici un article MSDN à ce sujet: Réorganisation et reconstruction des index
MISE À JOUR
En termes de temps nécessaire pour terminer l'opération, cela dépend évidemment de la fragmentation de l'index. La reconstruction d'un index extrêmement fragmenté prendra moins de temps que la réorganisation; la reconstruction d'un index légèrement fragmenté prendra beaucoup plus de temps. Je suggère de prendre les directives MS comme point de départ et d'exécuter des tests sur vos tables. Le seuil de rentabilité en termes de fragmentation% dépendra de la table spécifique, de la taille de l'index et du type de données.
la source
L'algorithme pour un REBUILD vs REORG est différent. Un REORG n'allouera PAS de nouvelles extensions par opposition à un RECONSTRUIRE. Un REORG fonctionnera avec les pages actuellement allouées (alloue une page aléatoire de 8 Ko pour qu'il puisse déplacer les pages) et les déplace, puis désalloue les pages si nécessaire.
D'après mes notes internes SQLSkills (anciennement IE0) ....
Pour RECONSTRUIRE:
Pour Index REORG:
À lire - Notes - Fragmentation, types et solutions d'index SQL Server
la source
Je sais que c'est du vieux fil, mais je pense qu'il sera bénéfique de partager le post de Paul Randal ici.
https://www.sqlskills.com/blogs/paul/sqlskills-sql101-rebuild-vs-reorganize/
la source
Oui, car généralement, une reconstruction doit analyser l'index d'origine dans l'ordre tout en diffusant les lignes (dans l'ordre) dans une nouvelle partition d'index physique. La fragmentation nuit aux analyses non mises en cache, donc oui, la reconstruction va prendre plus de temps.
La durée dépend de la fragmentation et de la façon dont le processeur est lié à l'ensemble du processus. La sérialisation des lignes est assez gourmande en CPU, donc cela peut ne pas avoir d'importance du tout. Ou, vous obtiendrez peut-être des taux d'E / S aléatoires généralement de 1,5 Mo / s, ce qui est facilement 5 à 10 fois plus lent qu'une reconstruction rapide (dépend du schéma et des données). En fonction des hypothèses que vous faites, vous pouvez probablement créer n'importe quoi entre un ralentissement 1x et 100x.
Ce n'est pas une relation linéaire. La métrique de fragmentation est un proxy très approximatif du temps qu'il faut pour analyser une partition.
la source
CHECKPOINT; DBCC DROPCLEANBUFFERSavant chaque test. Je suis également intéressé à voir les résultats. J'ai fait une fois un test similaire où j'ai mesuré la vitesse de numérisation en fonction de la fragmentation mais je ne me souviens pas du résultat.