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 .
