Fragmentation des fichiers physiques de la base de données SQL

Je sais qu'il y a vraiment trois types de fragmentation dont je dois m'inquiéter en tant que DBA:

1. 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+).

2. 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.

3. 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é.

Je pense que cet article donne un excellent aperçu de la défragmentation des disques SAN

http://www.las-solanas.com/storage_virtualization/san_volume_defragmentation.php

Les points de base sont que la défragmentation n'est pas recommandée sur le stockage SAN car il est difficile de corréler l'emplacement physique des blocs sur le disque lorsque l'emplacement a été virtualisé par le SAN lors de la présentation du LUN.

Si vous utilisiez des mappages de périphériques RAW ou si vous avez un accès direct à un ensemble RAID qui est le LUN avec lequel vous travaillez, je pourrais voir la dégfragmentation avoir un effet positif, mais si on vous donne un LUN "virtuel" sur un RAID partagé - 5 set, non.

Plusieurs parties à cette question et réponse:

La fragmentation physique des fichiers n'est pas vraiment pertinente pour le stockage SAN d'entreprise, comme Kevin l'a déjà souligné - donc rien à ajouter. Cela dépend vraiment du sous-système d'E / S et de la probabilité que vous puissiez faire passer les disques d'E / S plus aléatoires lors d'une analyse à des E / S plus séquentielles lors d'une analyse. pour DAS, il est plus probable que vous le fassiez, pour un SAN complexe slice-n-dice, probablement pas.

Défragmentation au niveau du système de fichiers - ne le faites qu'avec l'arrêt SQL. Je n'ai jamais rencontré de problèmes moi-même ici (car je n'ai jamais effectué de défragmentation en ligne et en fichier ouvert de fichiers de base de données SQL), mais j'ai entendu de nombreuses preuves anecdotiques de la part de clients et de clients de problèmes de corruption étranges. La sagesse générale est de ne pas le faire avec SQL en ligne.

La fragmentation d'index est complètement orthogonale à la fragmentation de fichier. SQL Server n'a aucune idée de la fragmentation des fichiers - trop de couches de virtualisation entre les deux pour qu'il puisse espérer travailler sur des géométries de sous-système d'E / S réelles. Fragmentation d'index, cependant, SQL sait tout sur. Sans trop me répéter à partir de la réponse que vous avez déjà référencée, la fragmentation de l'index empêchera SQL d'effectuer une lecture anticipée efficace de l'analyse de plage, quelle que soit la fragmentation (ou non) des fichiers au niveau du système de fichiers. Donc, vous devez absolument atténuer la fragmentation de l'index si vous constatez une dégradation des performances des requêtes.

Vous n'êtes pas obligé de les faire dans un ordre particulier, bien que si vous vous occupez de la fragmentation du système de fichiers, puis reconstruisez tous vos index et causez plus de fragmentation du système de fichiers en augmentant plusieurs fichiers sur un volume défraggé, vous allez probablement être coché. Cela causera-t-il des problèmes de performance? Comme discuté ci-dessus, cela dépend :-D

J'espère que cela t'aides!

Quelle est la meilleure façon de corriger la fragmentation physique des fichiers sur une boîte SQL de production?

J'exécute le contig de SYSINTERNALS sur mes fichiers de base de données.

Voir http://technet.microsoft.com/en-us/sysinternals/bb897428.aspx

Je recommanderais de dimensionner la base de données de manière appropriée, d'arrêter le serveur SQL, de copier le fichier de base de données sur une autre baie de disques, puis de le recopier pour le défragmenter. Beaucoup plus rapide que d'utiliser la défragmentation de Windows dans mon expérience.

J'ai essayé de défragmenter les disques physiques dans une solution scsi une fois, mais j'ai obtenu peu ou pas de boost de performance. La leçon que j'ai apprise est que si vous rencontrez des performances ralenties en raison du système de disque, cela n'a rien à voir avec la fragmentation, en ce qui concerne le fichier de données, car il utilise un accès aléatoire.

Si vos index sont défragmentés et que les statistiques sont mises à jour (très importantes) et que vous voyez toujours les E / S comme un goulot d'étranglement, vous souffrez d'autre chose que de la fragmentation physique. Avez-vous utilisé plus de 80% du disque? Avez-vous suffisamment de lecteurs? Vos requêtes sont-elles suffisamment optimisées? Faites-vous beaucoup de scan de table ou pire encore beaucoup de recherche d'index suivie d'une recherche d'index en cluster? Examinez les plans de requête et utilisez "Définir les statistiques sur" pour découvrir ce qui se passe réellement avec votre requête. (recherchez un nombre élevé de lectures logiques ou physiques)

Veuillez me faire savoir si je me trompe complètement.

/ Håkan Winther

Peut-être que les index ne sont pas suffisamment optimisés pour votre application et que vous n'avez pas Veritas I3 pour optimiser votre base de données, vous pouvez utiliser une instruction comme celle-ci pour trouver les index manquants:

       SELECT
      mid.statement,
      mid.equality_columns,
      mid.inequality_columns,
      mid.included_columns,
      migs.user_seeks,
      migs.user_scans,
      migs.last_user_seek,
      migs.avg_user_impact,
      user_scans,
      avg_total_user_cost,
      avg_total_user_cost * avg_user_impact * (user_seeks + user_scans) AS [weight]--, migs.*--, mid.*
   FROM
      sys.dm_db_missing_index_group_stats AS migs
      INNER JOIN sys.dm_db_missing_index_groups AS mig
         ON (migs.group_handle = mig.index_group_handle)
      INNER JOIN sys.dm_db_missing_index_details AS mid
         ON (mig.index_handle = mid.index_handle)
   ORDER BY
      avg_total_user_cost * avg_user_impact * (user_seeks + user_scans) DESC ;

Ou une instruction comme celle-ci pour rechercher des index qui ne sont pas utilisés dans les instructions select et diminue les performances de mise à jour / insertion:

    CREATE PROCEDURE [ADMIN].[spIndexCostBenefit]
    @dbname [nvarchar](75)
WITH EXECUTE AS CALLER
AS
--set @dbname='Chess'
declare @dbid nvarchar(5)
declare @sql nvarchar(2000)
select @dbid = convert(nvarchar(5),db_id(@dbname))

set @sql=N'select ''object'' = t.name,i.name
        ,''user reads'' = iu.user_seeks + iu.user_scans + iu.user_lookups
        ,''system reads'' = iu.system_seeks + iu.system_scans + iu.system_lookups
        ,''user writes'' = iu.user_updates
        ,''system writes'' = iu.system_updates
from '+ @dbname + '.sys.dm_db_index_usage_stats iu
,' + @dbname + '.sys.indexes i
,' + @dbname + '.sys.tables t
where 
    iu.database_id = ' + @dbid + '
and iu.index_id=i.index_id
and iu.object_id=i.object_id
and iu.object_id=t.object_id
AND (iu.user_seeks + iu.user_scans + iu.user_lookups)<iu.user_updates
order by ''user reads'' desc'

exec sp_executesql @sql

set @sql=N'SELECT
   ''object'' = t.name,
   o.index_id,
   ''usage_reads'' = user_seeks + user_scans + user_lookups,
   ''operational_reads'' = range_scan_count + singleton_lookup_count,
   range_scan_count,
   singleton_lookup_count,
   ''usage writes'' = user_updates,
   ''operational_leaf_writes'' = leaf_insert_count + leaf_update_count + leaf_delete_count,
   leaf_insert_count,
   leaf_update_count,
   leaf_delete_count,
   ''operational_leaf_page_splits'' = leaf_allocation_count,
   ''operational_nonleaf_writes'' = nonleaf_insert_count + nonleaf_update_count + nonleaf_delete_count,
   ''operational_nonleaf_page_splits'' = nonleaf_allocation_count
FROM
   ' + @dbname + '.sys.dm_db_index_operational_stats(' + @dbid + ', NULL, NULL, NULL) o,
   ' + @dbname + '.sys.dm_db_index_usage_stats u,
    ' + @dbname + '.sys.tables t
WHERE
   u.object_id = o.object_id
   AND u.index_id = o.index_id
    and u.object_id=t.object_id
ORDER BY
   operational_reads DESC,
   operational_leaf_writes,
   operational_nonleaf_writes'

exec sp_executesql @sql

GO

J'ai d'autres instructions SQL que j'utilise lorsque j'analyse les problèmes de performances dans l'environnement de production, mais ces deux sont un bon début, je pense.

(Je sais, ce post est un peu un sujet, mais j'ai pensé que cela pourrait vous intéresser car il a à voir avec la stratégie d'indexation)

/ Håkan Winther