Réduction d'une base de données
Chaque fichier d'une base de données peut être réduit afin de supprimer les pages inutilisées. Bien que le moteur de base de données réutilise l'espace efficacement, il arrive qu'un fichier n'ait plus besoin d'être aussi volumineux qu'il ne l'était, et que sa réduction devienne nécessaire. Cette réduction concerne aussi bien les fichiers de données que les journaux des transactions. Les fichiers de base de données peuvent être réduits manuellement, de manière groupée ou individuelle, ou automatiquement à des intervalles spécifiés, en configurant la base de données en ce sens.
Les fichiers sont toujours réduits à partir de la fin. Par exemple, si vous avez un fichier de 5 Go et spécifiez 4 Go comme target_size dans une instruction DBCC SHRINKFILE, le moteur de base de données libère autant d'espace qu'il le peut à partir du dernier 1 Go du fichier. S'il y a des pages utilisées dans la partie du fichier libérée, le moteur de base de données réalloue d'abord les pages dans la partie du fichier conservée. Une base de données peut être réduite tant qu'il existe de l'espace libre disponible. Par exemple, si une base de données de 5 Go a 4 Go de données et que vous spécifiez 3 Go comme target_size dans une instruction DBCC SHRINKFILE, seul 1 Go sera libéré.
Réduction automatique d'une base de données
Lorsque l'option de base de données AUTO_SHRINK est activée (ON), le moteur de base de données réduit automatiquement les bases de données qui contiennent de l'espace libre. L'option est définie au moyen de l'instruction ALTER DATABASE. La valeur OFF est choisie par défaut. Le moteur de base de données vérifie régulièrement l'utilisation de l'espace dans chaque base de données. Si l'option AUTO_SHRINK activée (ON) est activée pour une des bases de données, le moteur de base de données réduit la taille des fichiers dans la base de données. Cette opération se déroule en arrière-plan et ne gêne nullement les activités utilisateur dans la base de données.
Pour définir la réduction automatique d'une base de données
Réduction manuelle d'une base de données
Vous pouvez réduire manuellement une base de données ou certains de ses fichiers au moyen des instructions DBCC SHRINKDATABASE et DBCC SHRINKFILE. Si une instruction DBCC SHRINKDATABASE ou DBCC SHRINKFILE ne peut pas récupérer tout l'espace spécifié dans un fichier journal, elle émet un message d'information indiquant l'action que vous devez effectuer pour augmenter l'espace libérable. Pour plus d'informations sur la réduction des fichiers journaux, consultez Réduction du journal des transactions
Les opérations DBCC SHRINKDATABASE et DBCC SHRINKFILE peuvent être arrêtées à tout moment. Dans ce cas, le travail accompli est conservé.
L'instruction DBCC SHRINKDATABASE ne vous permet de réduire une base de données tout entière jusqu'à une taille inférieure à sa taille d'origine. Par conséquent, 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.
En revanche, l'instruction DBCC SHRINKFILE vous permet de réduire les fichiers individuels de la base de données à des tailles inférieures à celles de leur création. Vous devez réduire chaque fichier individuellement au lieu de réduire la base de données toute entière.
Notes
Vous ne pouvez pas réduire la base des données ou le journal des transactions pendant leur sauvegarde. Inversement, vous ne pouvez pas créer une sauvegarde de base de données ou de journal des transactions pendant une tentative de réduction de la base de données ou du journal des transactions.
Pour réduire une base de données
Pour réduire un fichier journal ou de données
Réduction du journal des transactions
La réduction d'un journal des transactions ne peut se faire qu'à partir de limites bien précises. La taille des fichiers journaux virtuels au sein du journal détermine la réduction possible en termes de taille. Par conséquent, le fichier journal ne peut jamais être réduit à une taille inférieure à celle du fichier journal virtuel. En outre, le fichier journal est réduit par incréments égaux à la taille du fichier journal virtuel. Par exemple, un journal des transactions initial de 1 Go peut contenir cinq fichiers journaux virtuels de 200 Mo chacun. La réduction du journal des transactions supprime les fichiers journaux virtuels inutilisés, mais en laisse au moins deux. Étant donné que, dans notre exemple, chaque fichier journal virtuel occupe 200 Mo, le journal des transactions ne peut être réduit qu'à 400 Mo au maximum, et uniquement par incréments de 200 Mo. Pour pouvoir réduire davantage un journal des transactions, créez un petit journal que vous laissez grandir automatiquement au lieu de créer un grand journal en une fois.
Une opération DBCC SHRINKDATABASE ou DBCC SHRINKFILE tente immédiatement de réduire le journal des transactions à la taille demandée (avec arrondi). Vous devez sauvegarder le fichier journal avant d'en réduire la taille logique et marquer comme inactifs les journaux virtuels qui ne comprennent aucune partie du fichier logique. Pour plus d'informations, consultez Réduction du journal des transactions.
Meilleures pratiques
Prenez en compte les informations suivantes lorsque vous envisagez de réduire une base de données ou un fichier :
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 troncation de table ou une suppression de table.
Pour la plupart des bases de données, un certain espace doit exister pour les opérations quotidiennes courantes. 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. Par exemple, vous ne devez pas réduire un fichier de données ou de base de donnes après avoir recréé des index. 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 exigence spécifique, vous ne devez pas affecter la valeur ON à l'option de base de données AUTO_SHRINK.
Opérations de réduction et niveaux d'isolement basé sur le versioning de ligne
Il est possible que des opérations de réduction soient bloquées par une transaction qui s'exécute sous un niveau d'isolement basé sur le versioning 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. Pour plus d'informations, consultez DBCC SHRINKDATABASE (Transact-SQL).