Je sais qu'il y a vraiment trois types de fragmentation dont je dois m'inquiéter en tant que DBA:
Fragmentation d' index dans les fichiers de données SQL, y compris la fragmentation d'index (table) en cluster. Identifiez cela à l'aide de DBCC SHOWCONTIG (dans SQL 2000) ou de sys.dm_ db_ index_ physical_ stats (en 2005+).
Fragmentation VLF à l' intérieur des fichiers journaux SQL. Exécutez DBCC LOGINFO pour voir combien de VLF se trouvent dans chacun de vos fichiers journaux SQL.
Fragmentation physique des fichiers de la base de données sur le disque dur. Diagnostiquez cela en utilisant l'utilitaire "Défragmenteur de disque" dans Windows. (inspiré par cet excellent article de blog )
Une grande attention est accordée à la fragmentation des index (voir cette excellente réponse Serverfault de Paul Randall), ce n'est donc pas l'objet de ma question.
Je sais que je peux empêcher la fragmentation physique (et la fragmentation VLF) lorsque la base de données est créée à l'origine en planifiant un fichier de données et une taille de journal raisonnablement attendus, car cette fragmentation se produit le plus souvent à cause de croissances et de réductions fréquentes, mais j'ai des questions sur la façon de résoudre ce problème fragmentation physique une fois identifiée:
Tout d'abord, la fragmentation physique est-elle même pertinente sur un SAN d'entreprise? Puis-je / dois-je utiliser le défragmenteur Windows sur un lecteur SAN, ou l'équipe SAN doit-elle utiliser des utilitaires de défragmentation internes? L'analyse de fragmentation obtenue à partir de l'outil Windows est-elle encore précise lorsqu'elle est exécutée sur un lecteur SAN?
Quelle est l'ampleur de la fragmentation physique des performances SQL? (Supposons une matrice de disques internes, en attendant le résultat de la question précédente.) Est-ce une affaire PLUS GRANDE que la fragmentation d'index interne? Ou est-ce vraiment le même genre de problème (le lecteur doit faire des lectures aléatoires au lieu de lectures séquentielles)
La défragmentation (ou la reconstruction) des index est-elle une perte de temps si le disque est physiquement fragmenté? Dois-je réparer l'un avant d'adresser l'autre?
Quelle est la meilleure façon de corriger la fragmentation des fichiers physiques sur une boîte SQL de production? Je sais que je peux désactiver les services SQL et exécuter Windows Defrag, mais j'ai également entendu parler d'une technique où vous effectuez une sauvegarde complète, supprimez la base de données, puis restaurez la sauvegarde sur un lecteur vide. Cette dernière technique est-elle recommandée? La restauration à partir d'une sauvegarde comme celle-ci crée-t-elle également des index à partir de zéro, éliminant la fragmentation interne des index? Ou retourne-t-il simplement l'ordre des pages de la même manière que lorsque la sauvegarde a été effectuée? (Nous utilisons des sauvegardes Quest Lightspeed avec compression, si cela importe.)
MISE À JOUR : Bonnes réponses à ce jour sur la défragmentation des disques SAN (NON) et si la défragmentation d'index vaut toujours la peine sur les disques physiquement fragmentés (OUI).
Quelqu'un d'autre veut-il peser sur les meilleures méthodes pour effectuer la défragmentation? Ou une estimation du temps que vous attendez pour défragmenter un gros disque fragmenté, disons 500 Go ou plus? Pertinent, évidemment, car c'est l'heure à laquelle mon serveur SQL sera en panne!
De plus, si quelqu'un a des informations anecdotiques sur les améliorations des performances SQL que vous avez apportées en corrigeant la fragmentation physique, ce serait bien aussi. Le billet de blog de Mike parle de la découverte du problème, mais ne précise pas le type d'amélioration qu'il a apporté.