Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

SQL Server - Disséquer les composants internes de sp_spaceused

Cet article est un effort pour disséquer la sortie du sp_spaceused procédure stockée.

Présentation

La compréhension de l'utilisation interne de la base de données et des tendances de croissance joue un rôle essentiel dans la définition du bon dimensionnement de la base de données. sp_spaceused est probablement la procédure stockée système la plus exécutée par un administrateur pour trouver l'espace disque utilisé par une base de données. Cela permet d'obtenir un aperçu rapide de l'utilisation de la base de données. statistiques. sp_spaceused est utilisé pour afficher le nombre de lignes, la taille des données, la taille de l'index, la quantité d'espace utilisé, l'espace inutilisé par chaque objet et la taille non allouée de la base de données. Bien qu'en regardant les valeurs données par sp_spaceused, il ne faut pas penser à réduire la base de données ou le fichier de données ou le fichier journal. Souvent, nous ne sommes pas conscients de ce que nous faisons. Souvent, nous ne savons pas quelles seraient les conséquences de telles opérations intrinsèques sur les ressources. La sortie de sp_spaceused nous en dit long sur les performances actuelles de la base de données. Le non alloué colonne et la colonne inutilisée indique l'espace libre restant au niveau de la base de données et de la table.

Cet article considère :

  1. Un aperçu de sp_spaceused
  2. Impact du paramètre de croissance automatique sur les colonnes, non allouées et inutilisées
  3. Trouver les détails de l'utilisation de l'espace au niveau de la base de données et des instances
  4. Mesurer les événements de croissance automatique
  5. Rechercher les tailles de fichier mdf et ldf
  6. Facteurs déterminant les performances de la base de données
  7. Et plus…

Internes de sp_spaceused

Capturer les détails d'utilisation de l'espace de toutes les tables

Dans le T-SQL ci-dessous, la procédure stockée non documentée sp_MSforeachtable est utilisée pour parcourir toutes les tables dans le cadre du contexte de base de données actuel afin d'obtenir les métriques d'utilisation de l'espace de toutes les tables du contexte.

Declare @tbl_sp_spaceused table(
    name varchar(100) NULL,
    rows bigint NULL,
    reserved varchar(20) NULL,
    data varchar(20) NULL,
    index_size varchar(20) NULL,
    unused varchar(20) NULL
    )

-- insert output of sp_spaceused to table variable

INSERT INTO @tbl_sp_spaceused ( name, rows, reserved, data, index_size, unused )
EXEC sp_MSforeachtable @command1 = 'EXEC sp_spaceused [?]'

SELECT *
FROM @tbl_sp_spaceused
order by rows desc

Capturer les détails d'utilisation de l'espace de toutes les bases de données

La procédure stockée non documentée sp_MSforeachDB est utilisée pour parcourir l'intégralité de la base de données dans le cadre de l'instance SQL actuelle afin d'obtenir les informations d'utilisation de l'espace de toutes les bases de données.

declare @tbl_sp_spaceusedDBs table(
    database_name varchar(100) NOT NULL,
    database_size varchar(50) NULL,
    unallocated varchar(30) NULL,
    reserved varchar(20) NULL,
    data varchar(20) NULL,
    index_size varchar(20) NULL,
    unused varchar(20) NULL
    )
INSERT INTO @tbl_sp_spaceusedDBs ( database_name, database_size, unallocated, reserved, data, index_size, unused )
EXEC sp_msforeachdb @command1="use ? exec sp_spaceused @oneresultset = 1"

SELECT *
FROM @tbl_sp_spaceusedDBs
ORDER BY database_name, database_size

Ici, database_name est le nom de la base de données ; dans ce cas, PythonSample . database_size est le Unalalloué+Réservé+Données+Index+Inutilisé =MDF +LDF (=848 Mo dans ce cas). Le non alloué l'espace ici est de 51,94 Mo.

Il s'agit en réalité de la limite du disque qui a été marquée pour la base de données. Le sp_spaceused génère une colonne non allouée définie au niveau de la base de données et n'est réservée à aucune table et peut être prise par le premier objet qui revendique plus d'espace pour se développer.

Le non alloué space est l'espace libre à l'intérieur du fichier de données afin qu'il n'ait pas à s'agrandir automatiquement à chaque fois que vous lancez une requête ; généralement, le moteur de stockage SQL Server gère la croissance automatique à l'aide d'un mécanisme appelé algorithme de remplissage proportionnel. La gestion des extensions se fait efficacement en fonction du nombre d'écritures se produisant sur les fichiers. Et en même temps, lorsque l'espace utilisé atteint un seuil, un événement est déclenché pour une croissance automatique supplémentaire. La définition de la bonne valeur d'espace non alloué dépend des besoins et des situations, et de la nature de l'utilisation de la base de données. L'espace non alloué est l'espace qui n'est pas encore utilisé et qui est "à gagner". Essentiellement, ces étendues sont marquées du bit 1 dans la page GAM. En comprenant le concept de croissance automatique d'en haut, tout type de croissance peut générer d'autres étendues non allouées.

À l'aide de la requête SQL suivante, nous pouvons voir le nombre de fois que l'événement de croissance automatique a été généré, ainsi que la durée pendant laquelle la base de données a été mise en attente pour le processus.

DECLARE @fname NVARCHAR(1000);

-- Get the name of the current default trace
SELECT @fname = CAST(value AS VARCHAR(MAX))
FROM ::fn_trace_getinfo(DEFAULT)
WHERE traceid = 1 AND property = 2;


SELECT 
	 ft.StartTime [Start Time]
	,t.name [Event Name]
	,DB_NAME(ft.databaseid) [Database Name]
	,ft.Filename [File Name]
	,(ft.IntegerData*8)/1024.0 [Growth MB]
	,(ft.duration/1000) [Duration MS]
FROM ::fn_trace_gettable(@fname, DEFAULT) AS ft 
INNER JOIN sys.trace_events AS t ON ft.EventClass = t.trace_event_id  
WHERE (ft.EventClass = 92  -- DateFile Auto-growth
    OR ft.EventClass = 93) -- LogFile Auto-growth
ORDER BY ft.StartTime

Voyons ce que chacun des termes signifie :

Réservé :L'espace réservé à l'usage des objets de la base de données =(Data +Index + Unused ) =476704 + 1280 + 1312 =479296 Ko. Cela indique le niveau de remplissage des objets ; idéalement, 10 % de l'espace inutilisé est prévu pour les tables transactionnelles.

Données :La taille réelle des données. C'est la somme de tous les fichiers de données de la base.

Index :La quantité d'espace utilisée par l'index.

Remarque :Dans certains cas, j'ai constaté que la taille de l'index était supérieure à la taille des données réelles. En ce qui concerne les index, ce dont le système a besoin dépend toujours des performances de la base de données. Souvent, les opérations de lecture sont plus importantes que les opérations d'écriture. Et dans certains autres cas, les écritures sont plus importantes que les lectures. Dans les cas où l'entreprise a décidé que les lectures sont bien plus importantes que les écritures, ce système peut avoir besoin de tonnes d'index afin de satisfaire les exigences de performance de l'entreprise et des utilisateurs.

Inutilisé :Une partie de l'espace réservé, qui n'est pas encore utilisé

Inutilisées sont des pages sur des étendues allouées mais qui ne sont encore utilisées par aucun objet. Dès qu'une étendue est allouée (en tant qu'étendue uniforme ou partagée), nous obtenons huit pages réservées sur cette étendue. Certaines pages sont utilisées et d'autres non utilisées.

Les inutilisés et non alloué colonnes dans la sortie peuvent prêter à confusion. Pour clarifier, le inutilisé la sortie de la colonne n'indique pas la quantité d'espace libre restant dans l'ensemble de la base de données. Il s'agit plutôt de la quantité totale d'espace réservée aux tables mais non remplie de données. Dans de nombreux cas, l'espace inutilisé peut être récupéré en créant un index clusterisé ou en gérant les index existants.

La sortie de sp_spaceused peut encore être simplifiée pour trouver la taille du fichier .mdf et des fichiers .log. La somme de l'espace réservé et de l'espace non alloué est plus ou moins égale à la taille du fichier de données (ou MDF). De plus, la soustraction de la taille du fichier MDF de la taille de la base de données donne la taille du fichier journal.

Voici donc deux formules :

Taille du fichier MDF =réservé + espace non alloué

Taille du fichier journal =Database_Size – Taille du fichier MDF

SELECT 476704+ 1280+ 1312 'Reserved KB', (479296/1024.00)+51.94 'MDFSizeMB', 848.00 - ((479296/1024.00)+51.94) 'LogSizeMB'

Les points susmentionnés nous indiquent comment chacune des colonnes de la sortie de sp_spaceused est interprétée, calculée et analysée.

Impact du paramètre de croissance automatique

Les tailles initiales et la configuration de croissance automatique ont un effet significatif sur l'espace inutilisé. Définir les bonnes valeurs pour ceux-ci est un défi. J'ai vu de nombreux cas où l'auto-croissance devait croître en termes de pourcentages. Supposons que la croissance automatique est définie sur 25 % pour une taille de fichier de données de 100 Go. Il suffit de 4 événements de croissance automatique pour remplir le lecteur de disque.

L'autre cas est la reconstruction des index. Cette opération a un impact direct sur l'espace inutilisé de la table, car les données sont redistribuées entre les étendues uniformes et mixtes. Dans quelques cas, lors du remaniement des pages, l'opération peut induire de l'espace non alloué en raison du paramètre de croissance automatique du fichier de données.

Considérons un scénario où le paramètre de croissance automatique n'est pas correctement défini sur la base de données. C'est encore un problème :si la croissance automatique est activée sur la base de données, cela signifie que l'expansion du lecteur a lieu automatiquement lors d'un événement, même si les données n'utilisent pas tout l'espace.

Il est toujours recommandé de définir le paramètre de croissance automatique approprié pour le fichier de données. Parfois, le réglage incorrect du fichier de données peut injecter une fragmentation physique, entraînant une grave dégradation des performances du système. En d'autres termes, si vous n'avez pas d'espace non alloué, les nouvelles données essaieront de s'asseoir dans des emplacements vides qui peuvent être dispersés. Cela s'applique également au fichier journal. L'espace non alloué dans la base de données influence indirectement le paramètre de croissance automatique du fichier de données et du fichier journal et influence directement les performances. La clé est de trouver le bon équilibre.

Conclusion

  1. Dans le processus de création de la base de données, la taille définie (c'est-à-dire la taille initiale) n'est rien d'autre que la taille réelle de la base de données. Cette taille initiale est enregistrée dans l'en-tête de page. Lors d'un processus de réduction de base de données, le processus utilise la taille minimale comme référence, uniquement si la taille réelle des données est inférieure à la taille minimale. La taille minimale se trouve également dans l'en-tête de page et peut être consultée à l'aide de la commande DBCC PAGE. En outre, le même processus s'applique à DBCC SHRINKFILE, qui réduit les fichiers à une taille inférieure à leur taille initiale.
  2. Il n'est pas recommandé de réduire la base de données pour libérer de l'espace disque, bien que la décision dépende du scénario :des scénarios inhabituels peuvent justifier une action non conventionnelle. Cependant, il faut se rappeler que la réduction d'une base de données introduit une fragmentation dans la base de données. Il est toujours recommandé d'analyser la cause première de l'espace non alloué et l'espace inutilisé des objets. Dans de nombreux cas, l'extension du disque pour gérer la croissance des données serait une option viable/recommandée.
  3. Configuration de croissance automatique :lorsque SQL Server effectue une opération de croissance automatique, la transaction qui a déclenché l'événement de croissance automatique doit attendre que l'événement de croissance automatique se termine. Ce n'est qu'alors que la transaction elle-même peut se terminer.
  4. Il est toujours recommandé de définir les options de croissance automatique en chiffres plutôt qu'en pourcentages.
  5. L'induction d'espace inutilisé dans le tableau peut être due aux raisons suivantes :
    • Fragmentation
      Lorsque les données sont fragmentées en raison de leur nature et du type de définition, de l'espace inutilisé est généré. De plus, une modification fréquente des données (toutes les opérations UPDATE, INSERT OR DELETE) entraîne un plus grand nombre de fractionnements de page, ce qui est plus susceptible de générer de l'espace inutilisé dans le tableau.
    • Pas d'index clusterisé sur la table
      Pour réduire la fragmentation dans un Heap, on peut penser à créer un index clusterisé sur la table. Pour réduire la fragmentation de l'index, effectuez la maintenance de l'index en déterminant la valeur avg_fragmentation_in_percent.
    • Taille des données
      Dans certains cas, l'utilisation de types de données appropriés produit des lignes de données plus petites, ce qui permet à son tour de placer plus de lignes dans une page. Cela réduit non seulement l'espace interne inutilisé, mais a également un impact sur les performances en réduisant le nombre de fractionnements de page.
  6. L'espace inutilisé peut également résulter de la suppression de la colonne de longueur variable. Utilisez DBCC CLEANTABLE après avoir apporté des modifications importantes aux colonnes de longueur variable dans une table ou une vue indexée afin de récupérer immédiatement l'espace inutilisé. Vous pouvez également reconstruire les index sur la table ou la vue ; cependant, il s'agit d'une opération plus gourmande en ressources.
  7. L'espace inutilisé est relativement plus important lorsque nous finissons par charger des données relativement plus volumineuses (>8 Ko). Dans de tels cas, nous nous retrouvons avec de grandes quantités d'espace inutilisé sur les pages de données.
  8. Après une migration SharePoint, on peut voir une quantité importante d'espace inutilisé introduit dans les bases de données. La récupération est un processus plus lent, le processus de nettoyage fantôme supprime ces pages et la libération se produit sur une période de temps.
  9. Dans certains cas, les valeurs de sp_spaceused peuvent ne pas être correctes. Bien que sp_spaceused obtienne ses informations de l'objet système qui contient toutes les estimations, elles peuvent parfois être inexactes. L'une des raisons en est que lors d'une migration de base de données, ou en cas de statistiques obsolètes, ou lorsque le système subit de fréquentes modifications DDL, ou après avoir effectué d'énormes opérations de copie en bloc. Pour synchroniser les objets système, utilisez les instructions DBCC updateusage(0) ou DBCC CHECKTABLE pour vous assurer que sp_spaceused renvoie des données exactes et à jour. Cependant, n'oubliez pas que les commandes DBCC sont gourmandes en ressources; avoir une bonne compréhension de l'implication de son utilisation. Lorsque nous exécutons la commande DBCC updateusage, le moteur de base de données SQL Server analyse les pages de données de la base de données et apporte les corrections nécessaires aux sys.allocation_units et sys.partitions vues de catalogue concernant l'espace de stockage utilisé par chaque table.

Références

  • https://msdn.microsoft.com/en-us/library/cc280360.aspx
  • https://docs.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-cleantable-transact-sql
  • https://docs.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-database-files-transact-sql