> Tech > Localisation de la fragmentation

Localisation de la fragmentation

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

La commande DBCC SHOWCONTIG de SQL Server constitue un outil utile pour vous aider à identifier l’étendue de la fragmentation dans une table. Malheureusement, l’exécution de la commande aggrave le problème que vous essayez de résoudre car elle crée des quantités importantes d’E/S. L’utilisation de l’option FAST diminue l’impact de

la commande sur les performances du serveur, mais même l’exécution de la commande DBCC SHOWCONTIG FAST ralentit de manière trop prononcée le système lorsque les performances sont déjà médiocres.

La réponse consiste à exécuter DBCC (Database Consistency Checker) lorsque vous avez le temps d’effectuer une analyse complète et à spécifier TABLERESULTS, afin que la sortie de l’analyse prenne la forme d’une table, puis à enregistrer le résultat. J’ai écrit la procédure stockée T-SQL uspBuildFraglist, dont le listing 1 présente un extrait, afin d’automatiser l’exécution de la commande DBCC SHOWCONTIG WITH TABLERESULTS. UspBuildFraglist effectue une boucle sur la liste de tables dans la base de données spécifiée et, pour chacune d’elles, exécute DBCC SHOWCONTIG WITH TABLERESULTS,ALL_INDEXES, afin d’afficher les informations de fragmentation pour les données et les index de la table spécifiée.

Les résultats sont, dans un premier temps, stockés dans une table temporaire, avant d’être transférés dans une table permanente située dans une base de données que j’ai créée en vue de contenir les données générées par des processus administratifs et de maintenance tels que celui-ci. La table permanente comporte une colonne LastScanTime afin de savoir à quel moment la table a été analysée. L’instruction IF du bloc A du listing 1 vérifie cette colonne pour chaque table et ignore l’instruction DBCC lorsque la table a été analysée au cours de la journée écoulée. Ce contrôle permet à uspBuildFraglist de s’exécuter plusieurs fois sans effectuer en double le travail réalisé par les analyses précédentes. Une deuxième fonctionnalité de usp- BuildFraglist est le délai après chaque analyse.

Le code du bloc B vérifie la table sysprocesses pour voir si le processus d’analyse bloque d’autres processus. Si c’est le cas, la procédure attend 30 secondes. Dans le cas contraire, la procédure attend 5 secondes avant d’effectuer l’analyse suivante. La possibilité d’une pause entre les analyses constitue le principal avantage de l’analyse individuelle de chaque table au lieu d’une analyse de toute la base de données en une seule fois. Il s’agit d’un procédé simple pour réduire au minimum les problèmes de blocage potentiels pouvant découler de l’exécution de DBCC.

Bien que la procédure stockée uspBuildFraglist effectue une tâche simple, elle vous permet de contrôler la fragmentation sans aggraver les problèmes de performances. Ayez à l’esprit que la procédure produira des résultats plus précis si vous l’exécutez après n’importe quelle tâche qui affecte les allocations de fichiers de base de données (par exemple, les tâches de réduction de base de données) ou purge les données.

Téléchargez cette ressource

Guide inmac wstore pour l’équipement IT de l’entreprise

Guide inmac wstore pour l’équipement IT de l’entreprise

Découvrez toutes nos actualités à travers des interviews, avis, conseils d'experts, témoignages clients, ainsi que les dernières tendances et solutions IT autour de nos 4 univers produits : Poste de travail, Affichage et Collaboration, Impression et Infrastructure.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010