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.

Figure 1.0 – Capture d’écran d’une analyse Diskeeper

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.

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.