Maintenir vos bases de données SQL Server™ défragmentées avec

Maintenir vos bases de données SQL Server™
défragmentées avec Diskeeper®
Toutes les bases de données SQL Server présentent, au fil du temps, une fragmentation « interne » de leurs données.
Elle se produit lorsque des enregistrements sont supprimés des pages de la base de données, mais que l’espace qu’ils
occupaient demeure après la suppression. Cet espace est finalement réutilisé mais, en raison de sa réutilisation, les pages
de données deviennent fragmentées, ce qui engendre des E/S inutiles, notamment en cas d’analyses de table impliquant
la lecture de nombreuses pages de données, l’une après l’autre.
SQL Server offre plusieurs moyens d’éliminer la fragmentation interne. L’une des méthodes consiste à utiliser la
commande DBCC REINDEX pour recréer des index ordonnés en cluster et non-cluster. Une fois les index recréés,
les pages de données présentent une contiguïté logique, ce qui minimise les E/S disque.
Malheureusement, le problème de la fragmentation ne se limite pas à la fragmentation interne. L’exécution de
DBCC REINDEX ne change en rien la fragmentation « externe ». Celle-ci représente la fragmentation des
fichiers sur les disques de votre serveur, qui provoque autant, voire plus, d’E/S inutiles que la fragmentation
interne. Les E/S inutiles, fort logiquement, dégradent les performances globales de SQL Server.
Les bases de données SQL Server consistent en de gros fichiers et journaux de base de données dont la taille est préallouée lors de leur création. Si l’espace libre contigu s’avère suffisant sur le disque à la création des fichiers d’origine, ils
ne sont pas alors fragmentés. Mais, si l’espace libre disponible n’est pas continu, les fichiers et journaux de base de
données sont alors fragmentés.
Même si les fichiers d’origine ne sont pas fragmentés lors de leur création initiale, ils vont presque certainement le
devenir au fil de la croissance de la base de données. Par exemple, si vous définissez pour la base de données
d’origine une taille de 100 Mo et pour le journal de 10 Mo tout en permettant la croissance automatique et aboutissez
à une taille de 5 Go pour la base de données et de 100 Mo pour le journal, la fragmentation externe risque d’être
considérable. Chaque croissance automatique des fichiers et journaux de base de données engendre un risque de
fragmentation externe.
Pour éliminer la fragmentation externe, il faut un utilitaire de système d’exploitation, et pas un utilitaire SQL
Server. L’un des outils les plus répandus pour défragmenter des fichiers de base de données SQL Server est
Diskeeper de Diskeeper Corporation. Diskeeper existe depuis de nombreuses années et beaucoup d’entre vous
connaissent déjà ce produit, au moins son utilisation pour des serveurs de fichiers Windows et d’impression.
Toutefois, beaucoup d’administrateurs ignorent qu’il s’agit du meilleur outil pour éliminer la fragmentation
externe de leurs bases de données SQL Server.
Lors de son exécution, un outil de défragmentation externe comme Diskeeper ne restructure pas le contenu
interne du fichier, contrairement à DBCC REINDEX. Lorsque Diskeeper a défragmenté un fichier, celui-ci est
identique bit par bit à l’original. Ainsi, tout espace vide dans la base de données existe toujours et vous devrez
toujours de temps en temps reconstruire vos index pour éliminer la fragmentation interne.
Un utilitaire tel que Diskeeper gère deux types de fragmentation externe : la fragmentation des fichiers et celle de
l’espace libre. La fragmentation des fichiers concerne les fichiers de disque de l’ordinateur qui ne se présentent pas
dans leur intégralité, mais sont plutôt scindés en plusieurs parties. La fragmentation de l’espace disque signifie que
l’espace libre sur un disque est disséminé en plusieurs parties et non regroupé dans son intégralité en un seul
espace libre important. La fragmentation des fichiers engendre des problèmes d’accès aux données stockées dans
les fichiers de disque de l’ordinateur alors que la fragmentation de l’espace libre provoque des problèmes pour
créer de nouveaux fichiers de données ou agrandir (ajouter du contenu) des fichiers existants.
Ainsi, lorsque Diskeeper s’exécute, il agit pour défragmenter les fichiers et journaux de base de données. De ce
fait, le fichier se présente sous la forme d’un segment continu et non en plusieurs parties éparpillées. De plus,
Diskeeper défragmente l’espace libre. Ainsi, les fichiers ou journaux peuvent augmenter en taille avec une
fragmentation faible ou nulle. Mais cela ne dure pas éternellement. Finalement, la fragmentation pose problème et
les fichiers et journaux de base de données doivent encore être défragmentés. Idéalement, la défragmentation doit
s’effectuer en temps réel pour éviter qu’une fragmentation inutile ne se produise et n’altère les performances.
Voici maintenant un point auquel vous n’avez certainement pas encore pensé. Quels sont les effets de la
fragmentation des fichiers sur la reconstruction de vos index SQL Server ? En d’autres termes, si vous n’effectuez
pas la défragmentation des fichiers mais exécutez une défragmentation interne des index/enregistrements, cela
présente-t-il des inconvénients ?
C’est en effet possible. Les fichiers étant fragmentés, SQL Server nécessite beaucoup plus de temps et d’E/S pour
reconstruire ses index sur des fichiers fragmentés que sur des fichiers contigus. Avant d’exécuter un processus de
défragmentation interne, il est donc conseillé d’exécuter d’abord un processus de défragmentation des fichiers.
Ainsi, vous réduisez le temps nécessaire à la reconstruction de vos index et la charge en E/S sur votre serveur
pendant cette opération.
Alors que la fragmentation des fichiers et journaux de base de données SQL Server peut dégrader les performances de
SQL Server, n’oubliez pas que l’outil accède à d’autres fichiers, tels que les fichiers exécutables SQL Server ou bien les
fichiers d'indexation de texte intégral si vous utilisez cette fonction. Ainsi, n’envisagez pas seulement de défragmenter les
fichiers et journaux de base de données SQL Server mais aussi tous les fichiers du serveur SQL Server.
Lors d’un processus de défragmentation Diskeeper, le
système d’exploitation gère lui-même tous les
transferts de fichiers. En réalité, le code du système
d’exploitation, coécrit à l'origine par Diskeeper
Corporation, privilégie la sécurité en déterminant ce qui
peut être défragmenté ou pas. Les bases de données
SQL Server (par exemple, LDF, MDF) peuvent être
défragmentées sans aucun risque. Puisque Diskeeper
envoie des requêtes au système d’exploitation (via
une API) pour transférer des fichiers, s’il rencontre
des fichiers qui ne peuvent pas être transférés en
toute sécurité, il les ignore simplement sans aucune
erreur ou autre problème.
Figure 1.0 – Capture d’écran d’une analyse Diskeeper
Mais, comment procédez-vous pour déterminer si les
fichiers de SQL Server sont fragmentés ? Heureusement, cela est facile. Dans le cadre des fonctionnalités de Diskeeper,
vous pouvez exécuter une analyse de fragmentation pour connaître l’état de fragmentation de vos fichiers SQL Server.
Tout comme pour la défragmentation, cela peut s'effectuer pendant le fonctionnement de SQL Server.
Comme vous pouvez l’imaginer, il s'avère difficile de recommander un délai spécifique au terme duquel exécuter la
défragmentation des fichiers, puisque chaque base de données est différente et que la fragmentation se produit à divers
rythmes. Une fonctionnalité Diskeeper dynamique permet de défragmenter en temps réel grâce à une technologie
exclusive appelée InvisiTasking™. Diskeeper ne défragmente les fichiers ou l’espace libre que si cela s’avère nécessaire.
De plus, InvisiTasking garantit une défragmentation transparente sans répercussion sur les ressources de SQL Server et
des autres applications en cours d’exécution. Enfin, vous pouvez toujours restreindre les périodes d’exécution de
Diskeeper si vous le souhaitez.
De nombreux administrateurs de bases de données qui achètent Diskeeper commencent par évaluer le produit
lorsqu’ils rencontrent des problèmes dont l’origine avérée réside dans des disques très fragmentés.
En général, c’est le cas si quelque chose tourne au ralenti. Lors de cette évaluation, ils utilisent des outils de
gestion et de surveillance des systèmes pour isoler précisément l’origine du problème. Cela est d’autant plus
vrai sur des serveurs SQL Server, car une fraction de seconde peut s’élever à des milliers de dollars en termes
de perte de revenus.
Schéma 1.1 – Capture d’écran de Diskeeper avec écran d’utilisation des ressources et de sélection du calendrier d’exécution
De nombreux articles techniques examinent des éléments spécifiques pour aider à diagnostiquer cette situation. L’un
de ces articles sur SQL Server s’intitule Troubleshooting Performance Problems in SQL Server 2005
(Résolution des problèmes de performance de SQL Server 2005).
Selon l’article Microsoft, ce qui suit indique le délai moyen (en secondes) de la lecture des données sur disque :
Moins de 10 ms = très bon
Entre 10-20 ms = bon
Entre 20-50 ms = lent, vigilance nécessaire
Supérieur à 50 ms = grave engorgement des E/S
Schéma 1.2 – Poste du rapport PerfMon.exe
Les études rapportées [à Diskeeper Corporation] par les administrateurs de bases de données SQL Server
ont montré que le délai moyen (en secondes) de la lecture des données sur disque était extrêmement élevé
sur leurs serveurs et présentait des temps de 200 ms et 300 ms, tout cela provoquant un grave engorgement
des E/S.
Comme prévu, l’article propose des solutions possibles pour résoudre les engorgements. Cependant, une solution
qui n'est pas explicitement mentionnée concerne la défragmentation des fichiers. La défragmentation à elle seule
a démontré qu’elle réduisait le délai moyen (en secondes) de la lecture des données sur disque, passant ainsi
d’une échelle de 200-300 ms à environ 15 et 30 ms, une optimisation extraordinaire en termes de performances !
Il n’est pas rare d’omettre la défragmentation sur la liste des solutions puisqu'elle reste méconnue par
beaucoup. Les recommandations données pour augmenter la bande passante des E/S, comme l’ajout de
nouveaux disques, sont des indicateurs que vous devez considérer comme présence possible d’une
fragmentation des fichiers. Exemple : votre fournisseur SAN vous demande d’ajouter un autre contrôleur ou
disque. En cas de fragmentation sensible, Diskeeper fournit généralement de meilleurs résultats, puisqu’en réalité
il résout le problème plutôt que de le dissimuler.
Schéma 1.3 – Rapport graphique PerfMon.exe
En résumé, un utilitaire de défragmentation des fichiers comme Diskeeper peut gérer la fragmentation externe du
disque tandis qu’un utilitaire SQL Server comme DBCC REINDEX peut traiter la fragmentation interne des
disques SQL Server. Ils peuvent fonctionner de concert pour assurer des performances optimales de vos
serveurs SQL Server.
En cas de doute quelconque, installez simplement Diskeeper et utilisez sa fonction d'analyse pour déterminer
précisément en combien de segments distincts votre fichier se divise. Vous allez probablement être très surpris. Il
est assez courant d’obtenir des rapports d’analyse indiquant des fichiers de base de données fragmentés en des
centaines de milliers de segments !
À propos des auteurs : Michael Materie est le directeur Gestion des produits de Diskeeper Corporation et conduit la stratégie directionnelle pour les logiciels
d’optimisation et de fiabilité de l'entreprise. Howard Butler est un ingénieur systèmes senior de Diskeeper Corporation. Il possède plus de 20 ans d’expérience
dans le domaine des performances des systèmes OpenVMS et Windows. Brad M. McGehee est un administrateur de bases de données à plein temps
dans une importante société industrielle. Il est l'éditeur de SQL-ServerPerformance.Com, un site Web spécialisé dans la configuration des performances
SQL Server et le clustering.
Réédité, en partie, avec l'autorisation de SQL-Server-Performance.Com © 2000 - 2011 SQL-Server-Performance.Com Tous droits réservés. Diskeeper
Corporation, Diskeeper et InvisiTasking sont des marques déposées ou des appellations commerciales de Diskeeper Corporation. Toutes les autres
marques appartiennent à leur propriétaire respectif.