DBCC SHRINKDATABASE (Transact-SQL)

Mis à jour : 14 avril 2006

Réduit la taille des fichiers de données et journaux dans la base de données spécifiée.

Conventions de syntaxe Transact-SQL

Syntaxe

DBCC SHRINKDATABASE 
( database_name | database_id | 0 
     [ ,target_percent ] 
     [ , { NOTRUNCATE | TRUNCATEONLY } ] 
)
[ WITH NO_INFOMSGS ]

Arguments

• database_name | database_id | 0
  Nom ou identificateur de la base de données à réduire. Si 0 est spécifié, la base de données actuelle est utilisée.

• target_percent
  Pourcentage d'espace que vous voulez laisser disponible dans le fichier de la base de données après sa réduction.

• NOTRUNCATE
  Compacte les données des fichiers de données en déplaçant les pages allouées de la fin du fichier vers les pages non allouées du début du fichier. target_percent est facultatif.

  L'espace libre à la fin du fichier n'est pas restitué au système d'exploitation et la taille physique du fichier ne change pas. Ainsi, lorsque l'option NOTRUNCATE est spécifiée, la base de données ne paraît pas être réduite.

  NOTRUNCATE n'est applicable qu'aux fichiers de données. Les fichiers journaux ne sont pas affectés.

• TRUNCATEONLY
  Libère pour le système d'exploitation tout l'espace libre à la fin du fichier, mais n'effectue aucun déplacement de page au sein du fichier. Le fichier de données est réduit seulement jusqu'à la dernière extension allouée. target_percent est ignoré s'il est spécifié avec l'option TRUNCATEONLY.

  TRUNCATEONLY n'est applicable qu'aux fichiers de données. Les fichiers journaux ne sont pas affectés.

• WITH NO_INFOMSGS
  Supprime tous les messages d'information dont les niveaux de gravité sont compris entre 0 et 10.

Jeux de résultats

Le tableau suivant décrit les colonnes du jeu de résultats.

Remarque :
Le moteur de base de données n'affiche pas de lignes pour les fichiers qui ne sont pas réduits.

Notes

Pour réduire tous les fichiers de données et fichiers journaux d'une base de données particulière, exécutez la commande DBCC SHRINKDATABASE. Pour réduire un fichier de données ou un fichier journal d'une base de données particulière, exécutez la commande DBCC SHRINKFILE.

Pour visualiser la quantité d'espace actuellement libre (non allouée) dans la base de données, exécutez sp_spaceused.

Les opérations DBCC SHRINKDATABASE peuvent être arrêtées à n'importe quel stade du processus, chaque travail terminé étant conservé.

La base de données ne peut pas être réduite à une taille inférieure à la taille minimale de la base de données. La taille minimale correspond à la taille spécifiée lors de la création initiale de la base de données ou à la dernière taille explicitement spécifiée à l'aide d'une opération de modification de taille de fichier, notamment en utilisant l'instruction DBCC SHIRNKFILE ou ALTER DATABASE. Par exemple, la plus petite taille que pourrait avoir une base de données de 10 Mo initialement et de 100 Mo avant réduction, même si toutes les données qu'elle contient ont été supprimées, est de 10 Mo après réduction.

Exécuter DBCC SHRINKDATABASE sans spécifier l'option NOTRUNCATE ou TRUNCATEONLY revient à exécuter une opération DBCC SHRINKDATABASE avec NOTRUNCATE suivie d'une opération DBCC SHRINKDATABASE avec TRUNCATEONLY.

Il n'est pas nécessaire que la base de données réduite soit mono-utilisateur ; d'autres utilisateurs peuvent travailler sur cette base au cours de l'opération. Ceci inclut également les bases de données système.

Vous ne pouvez pas réduire la taille d'une base de données en cours de sauvegarde. Inversement, vous ne pouvez pas sauvegarder une base de données alors qu'elle fait l'objet d'une opération de réduction.

Fonctionnement de DBCC SHRINKDATABASE

DBCC SHRINKDATABASE réduit les fichiers de données, fichier par fichier, mais réduit les fichiers journaux comme si les fichiers journaux existaient dans un groupe de journaux contigus. Les fichiers sont toujours réduits à partir de la fin.

Supposons que la base de données mydb a un fichier de données et deux fichiers journaux. La taille de chacun des fichiers est de 10 Mo et le fichier de données contient 6 Mo de données.

Pour chaque fichier, le moteur de base de données Microsoft SQL Server 2005 calcule une taille cible, qui est la taille à laquelle le fichier doit être réduit. Lorsque DBCC SHRINKDATABASE est spécifié avec target_percent, le moteur de base de données calcule la taille cible pour qu'elle corresponde au pourcentage target_percent d'espace disponible dans le fichier après la réduction. Par exemple, si vous attribuez la valeur 25 à target_percent pour la réduction de mydb, le moteur de base de données calcule 8 Mo pour la taille cible du fichier de données (6 Mo de données plus 2 Mo d'espace libre). Ainsi, le moteur de base de données déplace toutes les données dans les 2 derniers Mo du fichier de données vers l'espace libre dans les 8 premiers Mo du fichier de données, puis réduit le fichier.

Supposons que le fichier de données de mydb contienne 7 Mo de données. L'affectation de la valeur 30 à target_percent permet à ce fichier de données de dégager 30 % d'espace libre. L'affectation de la valeur 40 à target_percent ne permettra toutefois pas de réduire le fichier de données puisque le moteur de base de données ne peut pas réduire un fichier à une taille inférieure à celle des données actuellement présentes dans le fichier. Ce problème peut également être envisagé autrement : 40 % d'espace libre souhaité ajoutés à 70 % pour la taille du fichier de données (7 Mo sur 10 Mo) dépassent 100 %. Comme le pourcentage d'espace libre souhaité, augmenté du pourcentage actuel occupé par les données est supérieur (de 10 %) à 100 %, toute valeur de target_size supérieure à 30 n'entraîne pas la réduction du fichier de données.

Pour les fichiers journaux, le moteur de base de données utilise target_percent pour calculer la taille cible du fichier journal complet. La valeur en pourcentage de target_percent correspond donc à l'espace libre dans le journal après l'opération de réduction. La taille cible pour le journal complet est alors convertie en taille cible pour chaque fichier journal.

DBCC SHRINKDATABASE essaie immédiatement de réduire chaque fichier journal physique à sa taille cible. Si aucune partie du journal logique ne se trouve dans les journaux virtuels au-delà de la taille cible du fichier journal, le fichier est tronqué avec succès et DBCC SHRINKDATABASE s'exécute normalement sans émettre de messages. Cependant, si une partie du journal logique se trouve dans les journaux virtuels au-delà de la taille cible, le moteur de base de données libère autant d'espace que possible, puis émet un message d'information. Le message décrit les actions à effectuer pour déplacer le journal logique à partir des journaux virtuels à la fin du fichier. Lorsque les actions sont effectuées, DBCC SHRINKDATABASE peut être utilisé pour libérer l'espace restant. Pour plus d'informations, consultez Réduction du journal des transactions.

Comme un fichier journal ne peut être réduit que jusqu'à une limite virtuelle, il arrive qu'il ne soit pas possible de réduire un fichier journal à une taille inférieure à celle d'un fichier journal virtuel, même s'il n'est pas utilisé. La taille du fichier journal virtuel est choisie dynamiquement par le moteur de base de données au moment de la création ou de l'extension des fichiers journaux. Pour plus d'informations sur les fichiers du journal virtuel, consultez Architecture physique du journal des transactions.

Meilleures pratiques

Prenez en compte les informations suivantes lorsque vous envisagez de réduire une base de données :

• Une opération de réduction de taille de fichier est plus efficace après l'exécution d'une opération qui crée une grande quantité d'espace inutilisé, telle qu'une troncature de table ou une suppression de table.
• Un certain espace libre doit exister pour les opérations quotidiennes courantes pour la plupart des bases de données. Si vous réduisez plusieurs fois la taille d'une base de données et que vous constatez que la taille augmente de nouveau, cela indique que l'espace qui a été réduit est nécessaire pour les opérations courantes. Dans ce cas, la réduction de la taille de la base de données ne sert à rien.
• Une opération de réduction ne conserve pas l'état de fragmentation des index de la base de données, et augmente généralement la fragmentation. Il s'agit là d'une raison supplémentaire pour ne pas réduire la taille de la base de données de manière répétitive.
• Sauf en cas de besoin précis, n'attribuez pas la valeur ON à l'option de base de données AUTO_SHRINK.

Dépannage

Il est possible que les opérations de réduction soient bloquées par une transaction en cours d'exécution sous un niveau d'isolation basé sur les versions de ligne. Par exemple, si une grosse opération de suppression exécutée sous un niveau d'isolement basé sur le versioning de ligne est en cours lors de l'exécution d'une opération DBCC SHRINK DATABASE, l'opération de réduction attendra que l'opération de suppression soit terminée avant de réduire les fichiers. Dans ce cas, les opérations DBCC SHRINKFILE et DBCC SHRINKDATABASE envoient un message d'information (5202 pour SHRINKDATABASE et 5203 pour SHRINKFILE) dans le journal des erreurs SQL Server toutes les cinq minutes au cours de la première heure, puis toutes les heures. Par exemple si le journal des erreurs contient le message d'erreur :

DBCC SHRINKDATABASE for database ID 9 is waiting for the snapshot 
transaction with timestamp 15 and other snapshot transactions linked to 
timestamp 15 or with timestamps older than 109 to finish.

cela signifie que l'opération de réduction est bloquée par des transactions de capture instantanée ayant des valeurs d'horodateur plus anciennes que 109, qui est le numéro de la dernière transaction que l'opération de réduction a effectuée. Cela indique également que la colonne transaction_sequence_num ou first_snapshot_sequence_num de la vue de gestion dynamique sys.dm_tran_active_snapshot_database_transactions contient une valeur de 15. Si la colonne transaction_sequence_num ou first_snapshot_sequence_num de la vue contient un numéro inférieur à la dernière transaction réalisée par une opération de réduction (109), celle-ci attend la fin de ces transactions.

Pour résoudre ce problème, vous pouvez effectuer l'une des opérations suivantes :

• Achevez la transaction qui bloque l'opération de réduction.
• Achevez l'opération de réduction. Tout travail achevé sera conservé.
• Laissez simplement l'opération de réduction attendre que la transaction de blocage s'achève.

Pour plus d'informations sur le journal des erreurs SQL Server, consultez Consultation du Journal des erreurs de SQL Server.

Autorisations

Nécessite l'appartenance au rôle de serveur fixe sysadmin ou au rôle de base de données fixe db_owner.

Exemples

A. Réduction de la taille d'une base de données et spécification d'un pourcentage d'espace libre

L'exemple suivant diminue la taille des fichiers de données et journaux de la base de données utilisateur UserDB pour obtenir 10 % d'espace libre dans la base de données.

DBCC SHRINKDATABASE (UserDB, 10);
GO

B. Troncation d'une base de données

L'exemple suivant réduit la taille des fichiers de données de l'exemple de base de données AdventureWorks jusqu'à la dernière extension allouée.

DBCC SHRINKDATABASE (AdventureWorks, TRUNCATEONLY);

Voir aussi

Référence

ALTER DATABASE (Transact-SQL)
DBCC (Transact-SQL)
DBCC SHRINKFILE (Transact-SQL)

Autres ressources

Fichiers de bases de données et groupes de fichiers physiques
Procédure : réduction d'une base de données (SQL Server Management Studio)
Affectation et réutilisation de l'espace

Aide et Informations

Assistance sur SQL Server 2005

Historique des modifications