Article
09/27/2010

Réduction du journal des transactions

Si vous savez qu'un fichier journal de transactions contient de l'espace inutilisé dont vous n'aurez pas besoin, vous pouvez libérer l'espace excédentaire en réduisant la taille du journal de transactions. Ce processus est connu sous le nom de réduction du fichier journal.

Une réduction ne peut avoir lieu que lorsque la base de données est en ligne et, également, lorsqu'au moins un fichier journal virtuel est libre. Dans certains cas, la réduction du journal peut n'être possible qu'après la troncation de journal suivante.

[!REMARQUE]

En règle générale, une troncation se produit automatiquement en mode de récupération simple lorsque la base de données est sauvegardée et en mode de récupération complète lorsque le journal de transactions est sauvegardé. Toutefois, la troncation peut être différée par plusieurs facteurs. Pour plus d'informations, consultez Facteurs pouvant retarder la troncation du journal.

Pour réduire un fichier journal (sans réduire les fichiers de base de données)

Pour surveiller les événements de réduction du fichier journal

Classe d'événements Log File Auto Shrink.

To monitor log space

DBCC SQLPERF (Transact-SQL)
sys.database_files (Transact-SQL) (consultez les colonnes size, max_size et growth du ou des fichiers journaux.)

[!REMARQUE]

Il est possible de définir une réduction automatique des fichiers de la base de données et des fichiers journaux. Toutefois, nous vous déconseillons la réduction automatique, et la propriété de base de données autoshrink est définie par défaut par la valeur FALSE. Si autoshrink est définie par la valeur TRUE, la troncation automatique réduit la taille d'un fichier uniquement lorsque plus de 25 pour cent de son espace est inutilisé. Le fichier est réduit soit à la taille à laquelle seuls 25 % de ce dernier sont inutilisés soit à sa taille d'origine, selon la valeur la plus élevée. Pour plus d'informations sur la modification du paramètre de la propriété autoshrink, consultez Procédure : afficher ou modifier les propriétés d'une base de données (SQL Server Management Studio) et utilisez la propriété Réduction automatique de la page Options, ou consultez Options SET de ALTER DATABASE (Transact-SQL) et utilisez l'option AUTO_SHRINK.

Fonctionnement de la réduction du fichier journal

Le fait de réduire le journal des transactions permet de diminuer sa taille physique en supprimant un ou plusieurs fichiers journaux virtuels inactifs. Le fichier journal virtuel est toujours l'unité employée pour la réduction de la taille. Par exemple, si vous disposez d'un fichier journal de 600 mégaoctets (Mo) divisé en six journaux virtuels de 100 Mo, la taille du fichier journal peut uniquement être réduite par incréments de 100 Mo. La taille du fichier peut être réduite à 500 ou 400 Mo, mais ne peut pas être réduite à 433 Mo ou 525 Mo. Un fichier journal virtuel contenant des enregistrements de journal actifs (on parle alors de fichier journal virtuel actif) fait partie inhérente du journal logique et ne peut pas être supprimé. Pour plus d'informations, consultez Architecture physique du journal des transactions.

[!REMARQUE]

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. Pour plus d'informations, consultez Architecture physique du journal des transactions.

La taille actuelle d'un fichier journal est identique à la taille totale des pages employées par les fichiers journaux virtuels. Notez toutefois que les pages ne sont pas utilisées par les fichiers journaux. Les fichiers journaux virtuels qui contiennent une partie du journal logique ne peuvent pas être libérés. Si tous les fichiers journaux virtuels dans un fichier journal contiennent des parties du journal logique, le fichier ne peut pas être réduit. La réduction n'est pas possible tant que le journal tronqué ne signale pas un ou plusieurs fichiers journaux virtuels comme inactifs.

Une opération de réduction de fichier permet de supprimer uniquement les fichiers journaux virtuels inactifs. Si aucune taille cible n'est spécifiée, une opération de réduction de fichier supprime seulement les fichiers journaux virtuels au-delà du dernier fichier journal virtuel actif dans le fichier. Si une taille cible est définie, elle supprime seulement un nombre suffisant de fichiers journaux virtuels inactifs pour atteindre, sans la dépasser, la taille cible. Après réduction, la taille du fichier journal est généralement un tantinet supérieure à la taille cible mais elle ne sera jamais inférieure. Avec les fichiers journaux virtuels, il est difficile de prévoir dans quelle proportion le fichier journal sera réellement réduit.

Lorsqu'un fichier est réduit, l'espace libéré doit provenir de la fin du fichier. Lorsqu'un fichier journal de transactions est réduit, un nombre suffisant de fichiers journaux virtuels sont libérés à la fin du fichier journal pour réduire le journal en fonction de la taille demandée par l'utilisateur. Le paramètre target_size spécifié par l'utilisateur est arrondi à la limite de fichier journal virtuel immédiatement supérieure. Par exemple, si un utilisateur définit un paramètre target_size d'une valeur de 325 Mo pour notre exemple de fichier de 600 Mo constitué de six fichiers journaux virtuels de 100 Mo, les deux derniers fichiers journaux virtuels sont supprimés et la nouvelle taille du fichier est de 400 Mo.

Une opération DBCC SHRINKDATABASE ou DBCC SHRINKFILE tente immédiatement de réduire le fichier journal physique à la taille demandée :

Si aucune partie du journal logique contenu dans les fichiers journaux virtuels ne dépasse la marque target_size, les fichiers journaux virtuels situés après la marque target_size sont libérés et l'instruction DBCC s'exécute correctement (sans message).

Si une partie du journal logique contenu dans les journaux virtuels dépasse la marque target_size, le moteur de base de données SQL Server libère autant d'espace que possible et publie un message d'information. Le message indique quelles actions effectuer pour supprimer le journal logique des journaux virtuels à la fin du fichier. Une fois cette intervention effectuée, vous pouvez émettre l'instruction DBCC de nouveau pour libérer le reste de l'espace.

Par exemple, supposons qu'un fichier journal de 600 Mo, constitué de six fichiers journaux virtuels, comporte un journal logique commençant dans le journal virtuel 3 et se terminant dans le journal virtuel 4 lorsque vous exécutez une instruction DBCC SHRINKFILE avec un paramètre target_size de 275 Mo, ce qui correspond au trois-quarts du journal virtuel 3.

Fichier journal avec 6 fichiers journaux virtuels avant réduction

Les fichiers journaux virtuels 5 et 6 sont libérés immédiatement parce qu'ils ne contiennent aucune partie du journal logique. Cependant, pour satisfaire la valeur spécifiée du paramètre target_size, le fichier journal virtuel 4 doit aussi être libéré, mais cela est impossible car il contient la partie finale du journal logique. Une fois les fichiers journaux virtuels 5 et 6 libérés, le moteur de base de données remplit la partie restante du fichier journal virtuel 4 d'enregistrements factices. La fin du fichier journal est alors placée de force à la fin du fichier journal virtuel 1. Dans la plupart des systèmes, toutes les transactions commençant dans le fichier journal virtuel 4 sont validées en quelques secondes. En d'autres termes, toute la partie active du journal est déplacée dans le fichier journal virtuel 1. Le fichier journal se présente désormais ainsi :

Le fichier journal est réduit en 4 fichiers virtuels

L'instruction DBCC SHRINKFILE émet également un message d'information indiquant qu'elle n'a pas pu libérer tout l'espace demandé, et que vous pouvez exécuter une instruction BACKUP LOG pour libérer l'espace restant. Une fois la portion active du journal transférée dans le fichier journal virtuel 1, une instruction BACKUP LOG tronque la totalité du journal logique résidant dans le fichier journal virtuel 4 :

Résultats du fichier journal après troncation du journal

Puisque le fichier journal virtuel 4 ne contient plus aucune partie du journal logique, vous pouvez à présent exécuter la même instruction DBCC SHRINKFILE en attribuant au paramètre target_size une valeur de 275 Mo. Le fichier journal virtuel 4 est alors libéré et la taille du fichier journal physique est réduite à la taille que vous avez demandée.

[!REMARQUE]

Certains facteurs, comme les transactions longues, peuvent conserver les fichiers journaux virtuels pendant une période étendue. Il peut s'ensuivre une restriction du fichier journal ou une impossibilité totale de réduction du fichier journal. Pour plus d'informations, consultez Facteurs pouvant retarder la troncation du journal.