FICHIER DE RÉDUCTION DBCC (Transact-SQL)

S’applique à :SQL Server Azure SQL Database Azure SQL Managed Instance Base de données SQL dans Microsoft Fabric

Réduit la taille de fichier journal ou de données de la base de données active. Vous pouvez l’utiliser pour déplacer des données entre fichiers du même groupe de fichiers, ce qui a pour effet de supprimer le fichier d’origine et de permettre sa suppression de la base de données. Il est possible de réduire un fichier à une taille inférieure à celle qu’il avait à sa création, réinitialisant ainsi la taille de fichier minimale sur la nouvelle valeur.

À utiliser DBCC SHRINKFILE uniquement lorsque cela est nécessaire, car le rétrécissement est une opération longue et gourmande en ressources.

Remarque

Ne considérez pas les opérations de réduction comme un entretien régulier. Les fichiers de données et de journaux qui augmentent en raison d’opérations métier régulières et récurrentes ne nécessitent pas d’opérations de réduction.

Conventions de la syntaxe Transact-SQL

Syntaxe

DBCC SHRINKFILE
(
    { file_name | file_id }
    { [ , EMPTYFILE ]
    | [ [ , target_size ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ]
    }
)
[ WITH
  {
      [ WAIT_AT_LOW_PRIORITY
        [ (
            <wait_at_low_priority_option_list>
        ) ]
      ]
      [ , NO_INFOMSGS ]
  }
]

<wait_at_low_priority_option_list> ::=
    <wait_at_low_priority_option>
    | <wait_at_low_priority_option_list> , <wait_at_low_priority_option>

<wait_at_low_priority_option> ::=
    ABORT_AFTER_WAIT = { SELF | BLOCKERS }

Les arguments

file_name

Le nom logique du fichier est de rétrécir.

file_id

Le numéro d’identification (ID) du fichier à réduire. Pour récupérer l’ID d’un fichier, utilisez la fonction système FILE_IDEX ou interrogez l’affichage catalogue sys.database_files dans la base de données active.

target_size

Nombre entier représentant la nouvelle taille du fichier en mégaoctets. Si vous target_size définissez sur 0 ou ne le spécifiez pas, DBCC SHRINKFILE le fichier réduit à sa taille de création.

Vous pouvez réduire la taille par défaut d’un fichier vide avec DBCC SHRINKFILE <target_size>. Par exemple, si vous créez un fichier de 5 Mo, puis que vous le réduisez à 3 Mo pendant que le fichier est encore vide, la taille de fichier par défaut est fixée à 3 Mo. Cela s'applique uniquement aux fichiers vides qui n'ont jamais contenu des données.

Cette option n'est pas prise en charge pour les conteneurs de groupe de fichiers FILESTREAM.

Si elle est spécifiée, DBCC SHRINKFILE tente de réduire le fichier à la taille définie par target_size. Les pages utilisées dans la zone du fichier à libérer sont déplacées dans l’espace libre des zones conservées du fichier. Par exemple, avec un fichier de données de 10 Mo, une opération de DBCC SHRINKFILE avec une cible de taille 8 déplace toutes les pages utilisées situées dans les 2 derniers Mo du fichier vers les pages non allouées dans les 8 premiers Mo du fichier. DBCC SHRINKFILE ne réduit pas un fichier au-delà de la taille des données stockées nécessaire. Par exemple, dans un fichier de 10 Mo où 7 Mo sont utilisés, une instruction DBCC SHRINKFILE avec une valeur target_size de 6 réduit la taille du fichier à 7 Mo et non pas à 6 Mo.

Si vous spécifiez target_size avec TRUNCATEONLY, DBCC SHRINKFILE il se peut que l’espace libre ne soit pas libéré à la fin du fichier.

FICHIER VIDE

Permet la migration de toutes les données du fichier spécifié vers d’autres fichiers dans le même groupe de fichiers. En d’autres termes, EMPTYFILE migre les données du fichier spécifié vers d’autres fichiers dans le même groupe de fichiers. EMPTYFILE permet de garantir qu’aucune nouvelle donnée ne peut être ajoutée au fichier, qui n’est pourtant pas en lecture seule. Vous pouvez utiliser cette ALTER DATABASE instruction pour supprimer un fichier. Si vous utilisez l’instruction ALTER DATABASE pour changer la taille du fichier, le drapeau en lecture seule est réinitialisé et les données peuvent être ajoutées.

Pour les conteneurs de groupes de fichiers FILESTREAM, il n’est pas possible de supprimer un fichier avec ALTER DATABASE tant que le récupérateur de mémoire FILESTREAM n'a pas été exécuté pour supprimer tous les fichiers inutiles d’un conteneur de groupes de fichiers que EMPTYFILE a copiés dans un autre conteneur. Pour plus d’informations, consultez sp_filestream_force_garbage_collection. Pour des informations sur la suppression d’un conteneur FILESTREAM, voir la section correspondante dans ALTER DATABASE Options de fichiers et groupes de fichiers

EMPTYFILEn'est pas pris en charge dans Azure SQL Database, Azure SQL Database Hyperscale, ou SQL Database dans Microsoft Fabric.

NOTRUNCATE

Déplace des pages allouées de la fin d’un fichier de données vers les pages non allouées du début d’un fichier, que target_percent soit spécifié ou non. 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. Par conséquent, si NOTRUNCATE est spécifié, le fichier ne semble pas se réduire.

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

Cette option n'est pas prise en charge pour les conteneurs de groupe de fichiers FILESTREAM.

TRUNCATEONLY

Libère tout l'espace libre à la fin du fichier pour le système d'exploitation, 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.

Si target_size est spécifié avec TRUNCATEONLY, l’espace libre à la fin du fichier peut ne pas être libéré.

L’option TRUNCATEONLY ne déplace pas les informations dans le journal, mais supprime les fichiers virtuels de journal inactifs (VLF) à la fin du fichier journal. Cette option n'est pas prise en charge pour les conteneurs de groupe de fichiers FILESTREAM.

AVEC NO_INFOMSGS

Supprime tous les messages d'information.

WAIT_AT_LOW_PRIORITY avec opérations de réduction

S’applique à : SQL Server 2022 (16.x) et versions ultérieures, Azure SQL Database, Azure SQL Managed Instance, base de données SQL dans Microsoft Fabric

La fonction d’attente à faible priorité réduit la contention de verrouillage lors de l’opération de rétrécition. Pour plus d’informations, voir Comprendre les problèmes de concurrence avec DBCC SHRINKFILE.

Cette fonctionnalité est similaire à WAIT_AT_LOW_PRIORITY avec des opérations d’indexation en ligne, à quelques différences près.

Vous ne pouvez pas spécifier l’option ABORT_AFTER_WAITNONE.
Tu ne peux pas définir cette MAX_DURATION option. Le délai de verrouillage à faible priorité pour une opération de réduction est toujours d’une minute.

WAIT_AT_LOW_PRIORITY

Lorsqu’une commande de réduction est exécutée en WAIT_AT_LOW_PRIORITY mode, les requêtes nécessitant des verrous de stabilité de schéma (Sch-S) sur les pages de la carte d’allocation d’index (IAM) ne sont pas bloquées par l’opération de réduction. Cependant, l’opération de réduction peut être bloquée par un Sch-S verrou sur une page IAM. Le réduction continue de s’exécuter uniquement lorsqu’il est capable d’obtenir un verrou de modification de schéma (Sch-M) sur une page IAM requise.

Si une opération de réduction en WAIT_AT_LOW_PRIORITY mode ne peut pas obtenir ce verrou en raison d’une requête longue qui détient un Sch-S verrou, l’opération de réduction expire avec l’erreur 49516, par exemple : Msg 49516, Level 16, State 1, Line 134 Shrink timeout waiting to acquire schema modify lock in WLP mode to process IAM pageID 1:2865 on database ID 5.

{ ABORT_AFTER_WAIT = [ SELF | BLOQUEURS ] }

S’applique à : SQL Server (SQL Server 2022 (16.x) et versions ultérieures), Azure SQL Database, base de données SQL dans Microsoft Fabric.

SELF

SELF est l’option par défaut. Quittez l’opération de réduction du fichier en cours d’exécution sans prendre d’autres mesures.
BLOCKERS

Tuez toutes les transactions utilisateur qui bloquent l'opération de réduction des fichiers afin que l'opération puisse continuer. L’option BLOCKERS exige que la connexion ait la ALTER ANY CONNECTION permission de Ou KILL DATABASE CONNECTION .

Jeu de résultats

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

Nom de la colonne	Descriptif
`DbId`	Numéro d'identification de base de données du fichier que le Moteur de base de données tente de réduire.
`FileId`	Numéro d’identification du fichier que le Moteur de base de données a tenté de réduire.
`CurrentSize`	Nombre de pages de 8 Ko que le fichier occupe actuellement.
`MinimumSize`	Nombre de pages de 8 Ko que le fichier pourrait occuper au minimum. Ce nombre correspond à la taille minimale ou à la taille de création d'un fichier.
`UsedPages`	Nombre de pages de 8 Ko que le fichier utilise actuellement.
`EstimatedPages`	Nombre de pages de 8 Ko estimé par le Moteur de base de données auquel la taille du fichier peut être ramenée.

Notes

DBCC SHRINKFILE s'applique aux fichiers de la base de données active. Pour plus d’informations sur la modification de la base de données actuelle, voir USE.

Les opérations DBCC SHRINKFILE peuvent être arrêtées à n'importe quel stade du processus, chaque travail terminé étant conservé. Si vous utilisez le paramètre EMPTYFILE et annulez l’opération, le fichier n’est pas marqué pour empêcher l’ajout de données supplémentaires.

D’autres utilisateurs peuvent travailler dans la base de données pendant la réduction des fichiers, même si la base de données n’est pas en mode mono-utilisateur. Il n'est pas nécessaire d'exécuter l'instance de SQL Server en mode mono-utilisateur pour réduire les bases de données système.

Problèmes connus

S’applique à : SQL Server, Azure SQL Database, SQL database in Microsoft Fabric, Azure SQL Managed Instance, Azure Synapse Analytics dédié SQL pool

Dans les versions SQL Server antérieures à SQL Server 2025 (17.x), les pages utilisées par les types de colonnes grand objet (LOB) (varbinary(max), varchar(max) et nvarchar(max)) dans les segments compressés de colonstocker ne peuvent pas être déplacées par DBCC SHRINKDATABASE et DBCC SHRINKFILE. Pour plus d’informations, consultez les nouveautés concernant les index columnstore.

Comprendre les problèmes de concurrence avec DBCC SHRINKFILE

Les commandes de réduction de base de données et de fichiers de réduction peuvent entraîner des problèmes de concurrence, notamment lors d’une maintenance active comme la reconstruction des index, ou dans des environnements de traitement de transactions en ligne (OLTP) très fréquentés.

Par exemple, une requête utilisateur peut acquérir un verrou de stabilité de schéma (Sch-S) sur une page d’allocation d’index (IAM) et le maintenir jusqu’à sa fin. Lors de tentatives de récupération d’espace lors d’une utilisation régulière, les opérations de réduction de base de données et de réduction de fichiers nécessitent un verrou de modification de schéma (Sch-M) lors du déplacement ou de la suppression de pages IAM, bloquant ainsi les Sch-S verrous nécessaires aux requêtes utilisateur. En conséquence, les requêtes de longue durée peuvent bloquer une opération de réduction. Cela signifie également que toute nouvelle requête nécessitant un Sch-S verrouillage sur une page IAM peut être placée en file d’attente derrière l’opération de réduction, aggravant encore ce problème de concurrence.

Introduite dans SQL Server 2022 (16.x), la fonctionnalité d’attente à faible priorité pour les opérations de réduction répond à ce problème en prenant le verrou de modification de schéma sur les pages IAM dans ce WAIT_AT_LOW_PRIORITY mode. Pour plus d’informations, consultez WAIT_AT_LOW_PRIORITY avec des opérations de réduction.

Pour plus d’informations sur Sch-S les verrous et Sch-M les serrures, consultez le guide de verrouillage des transactions et de versionnement des lignes.

Réduire un fichier journal

Dans le cas des fichiers journaux, le Moteur de base de données utilise target_size pour calculer la taille cible de l’ensemble du journal. Par conséquent, target_size correspond à l’espace libre du journal après l’opération de réduction. La taille cible de l'ensemble du journal est ensuite convertie en taille cible de chaque fichier journal. DBCC SHRINKFILE tente immédiatement de réduire la taille de chaque fichier journal physique à sa taille cible. Toutefois, 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 envoie 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. Une fois les actions exécutées, DBCC SHRINKFILE peut être utilisé pour libérer l’espace restant.

Comme un fichier journal ne peut être réduit que jusqu'à une limite de fichier journal virtuel, il n’est pas toujours possible de descendre au-dessous de cette taille limite, même si le fichier n'est pas utilisé. Le Moteur de base de données sélectionne dynamiquement la taille du fichier journal virtuel lorsque les fichiers journaux sont créés ou étendus.

Meilleures pratiques

Prenez en compte les informations suivantes lorsque vous envisagez de réduire un fichier :

Une opération de réduction est plus efficace après une opération qui crée une grande quantité d'espace inutilisé, par exemple TRUNCATE TABLE ou DROP 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’un fichier de bases de données et que vous constatez que la taille augmente de nouveau, cela indique que l’espace disponible est nécessaire pour les opérations courantes. Dans ces cas, réduire à plusieurs reprises le fichier de base de données est contre-productif. La croissance du fichier nécessaire pour allouer un nouvel espace après le retrait peut nuire aux performances.
Une opération de réduction ne préserve pas l’état de fragmentation des index dans la base de données, et peut augmenter la fragmentation des indices, ce qui pourrait réduire le débit d’E/S de lecture pour les requêtes utilisant de grands scans.
Si vous devez réduire les fichiers de données d’une grande base de données, envisagez d’utiliser le script PowerShell ShrinkDriver . Le script automatise et simplifie le processus de réduction, le transformant en une opération unique, observable et reprenable. Le script rétrécit plusieurs fichiers en parallèle, réessaie lorsqu’il est interrompu, et génère des rapports d’état détaillés au fur et à mesure.

Dépanner

Cette section décrit comment diagnostiquer et corriger les problèmes qui peuvent se produire lors de l'exécution de la commande DBCC SHRINKFILE.

Le fichier ne se réduit pas

Si la taille du fichier ne change pas après une opération de réduction sans erreur, essayez les étapes suivantes pour vérifier que le fichier dispose d’un espace libre suffisant :

Exécutez la requête suivante.

SELECT name,
       size / 128.0 - CAST (FILEPROPERTY(name, 'SpaceUsed') AS INT) / 128.0 AS AvailableSpaceInMB
FROM sys.database_files;

Si vous souhaitez réduire le fichier journal des transactions, utilisez la vue de gestion dynamique (DMV) sys.dm_db_log_space_usage pour voir l’espace utilisé dans le journal des transactions.

L’opération de réduction ne peut pas réduire davantage la taille du fichier s’il n’y a pas assez d’espace libre.

Une raison courante pour laquelle un fichier journal de transactions ne se rétrécit pas est l’absence de sauvegardes régulières des journaux de transactions. Pour tronquer le journal, sauvegardez le journal des transactions, puis réexécutez l’opération de DBCC SHRINKFILE. Si la récupération à un moment donné n'est pas nécessaire, envisagez les modèles de récupération (SQL Server) pour éviter la croissance des fichiers journaliers.

L'opération de réduction est bloquée

Une transaction qui s’exécute sous un niveau d’isolement basé sur le contrôle de version de ligne peut bloquer les opérations de réduction. Par exemple, si une opération de suppression de grande envergure sous un niveau d'isolation basé sur le contrôle de version de ligne s’exécute en parallèle d’une opération DBCC SHRINKDATABASE, l'opération de réduction attend la fin de l'opération de suppression pour continuer. Quand ce blocage se produit, les opérations DBCC SHRINKFILE et DBCC SHRINKDATABASE consignent un message d’information (5202 pour SHRINKDATABASE et 5203 pour SHRINKFILE) dans le journal des erreurs SQL Server. Ce message est consigné toutes les cinq minutes pendant la première heure, puis toutes les heures. Par exemple:

DBCC SHRINKFILE for file ID 1 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.

Ce message signifie que des transactions de capture instantanée présentant un timestamp antérieur à 109 (dernière transaction effectuée par l'opération de réduction) bloquent l'opération de réduction. Il indique également que la colonne transaction_sequence_num ou la colonne first_snapshot_sequence_num de la vue de gestion dynamique sys.dm_tran_active_snapshot_database_transactions contient la valeur 15. Si la colonne transaction_sequence_num ou la colonne first_snapshot_sequence_num contient un numéro inférieur à la dernière transaction effectuée par une opération de réduction (109), l'opération de réduction attend la fin de ces transactions.

Pour résoudre le problème, suivez l’une des étapes suivantes :

Mettez fin à la transaction qui bloque l'opération de réduction.
Mettez fin à l'opération de réduction. Le travail accompli sera conservé.
Laissez simplement l'opération de réduction attendre que la transaction bloquante s'achève.

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

Les exemples de code de cet article utilisent les bases de données d'exemple AdventureWorks2025 ou AdventureWorksDW2025, que vous pouvez télécharger à partir de la page d'accueil Microsoft SQL Server Samples and Community Projects.

R. Réduire un fichier de données à une taille cible spécifiée

L’exemple suivant ramène la taille d’un fichier de données nommé DataFile1 de la base de données utilisateur UserDB à 7 Mo.

USE UserDB;
GO

DBCC SHRINKFILE (DataFile1, 7);
GO

B. Réduire un fichier journal à une taille cible spécifiée

L'exemple suivant ramène la taille du fichier journal de la base de données AdventureWorks2025 à 1 Mo. Pour permettre à la DBCC SHRINKFILE commande de réduire le fichier, celui-ci est d’abord tronqué en définissant le modèle de récupération de la base de données à SIMPLE.

USE AdventureWorks2025;
GO

-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2025
    SET RECOVERY SIMPLE;
GO

-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2025_Log, 1);
GO

-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2025
    SET RECOVERY FULL;
GO

Chapitre C. Tronquer les fichiers de données

L'exemple suivant tronque le fichier de données primaire dans la base de données AdventureWorks2025. Le système interroge l'affichage catalogue sys.database_files afin d'obtenir la valeur file_id du fichier de données.

USE AdventureWorks2025;
GO

SELECT file_id,
       name
FROM sys.database_files;
GO

DBCC SHRINKFILE (1, TRUNCATEONLY);

D. Vider un fichier

L'exemple suivant montre comment vider un fichier de manière à ce qu'il puisse être supprimé de la base de données. Dans ce cadre, un fichier de données est d’abord créé ; il contient des données.

USE AdventureWorks2025;
GO

-- Create a data file and assume it contains data.
ALTER DATABASE AdventureWorks2025
    ADD FILE (NAME = Test1data, FILENAME = 'C:\t1data.ndf', SIZE = 5 MB);
GO

-- Empty the data file.
DBCC SHRINKFILE (Test1data, EMPTYFILE);
GO

-- Remove the data file from the database.
ALTER DATABASE AdventureWorks2025
     REMOVE FILE Test1data;
GO

E. Réduire un fichier de base de données avec WAIT_AT_LOW_PRIORITY

L’exemple suivant tente de réduire la taille d’un fichier de données dans la base de données utilisateur actuelle à 1 Mo. La vue catalogue sys.database_files est interrogée pour obtenir le file_id du fichier de données (dans cet exemple, file_id 5). Si un verrou ne peut pas être obtenu dans un délai d’une minute, l’opération de réduction abandonne.

USE AdventureWorks2025;
GO

SELECT file_id,
       name
FROM sys.database_files;
GO

DBCC SHRINKFILE (5, 1) WITH WAIT_AT_LOW_PRIORITY (ABORT_AFTER_WAIT = SELF);

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-07-24