Quelque soit le nombre de fichiers physique définis pour le journal des transaction, SQL Server traite toujours le journal comme un fichier contigu. par exemple, lorsque la commande DBCC SHRINKDATABASE détermine de combien le journal peut réduit, il considère les fichiers du journal en déterminant la taille de réduction basée sur le fichier entier.

Le journal des transactions de chaque base est géré comme un ensemble de VLFs (Virtual Log Files) dont la taille est déterminée en interne, et basée sur la taille totale de tous les fichiers du journal et de l'incrément du journal. Un journal est étendu en unités de VLFs et ne peut être réduit qu'à la limite d'un VLF (Figure 5-2). Un VLF existe dans un de ces trois états:

• Actif La portion active du journal commence à partir du LSN minimum (log sequence number qui représente une transaction active (non validée). La portion active du journal se termine au dernier LSN écrit. Chaque VLF qui contient une partie de journal actif est considéré comme actif. (L'espace non utilisé dans le journal physique ne fait pas parti des VLFs.)
• Récupérable La portion de journal précédant la plus vieille transaction active ne sert qu'à maintenir une séquence de sauvegardes de journal pour les besoins de récupération.
• Réutilisable Si les sauvegardes du journal des transactions ne sont pas maintenues ou si le journal a déjà été sauvegardé, les VLFS qui sont avant les plus vieilles transactions actives ne sont pas utilisées et peuvent être réutilisés.

Figure 5-2. Les fichiers de journal virtuels (VLF) qui font un fichier journal physique.

SQL Server déduit que vous ne maintenez pas une séquence de sauvegardes de journal si un des conditions est vérifiée:

• Vous avez tronqué le journal avec BACKUP LOG WITH NO_LOG ou BACKUP LOG WITH TRUNCATE_ONLY.
• Vous avez positionné l'option trunc. log on chkpt pour réaliser la réduction du journal automatiquement.
• Vous avez lancé une command qui n'écrit rien au journal (comme BCP) avant la dernière sauvegarde complète de base de données.
• Vous n'avez fait de sauvegarde complète de base de données.

Dans ces situations, lorsque SQL Server atteint la fin du fichier journal, il continuera en réutilisant ce fichier de manière circulaire, en partant du début. SQL Server recycle l'espace du fichier journal qui n'est plus nécessaire pour des opérations de récupération ou de sauvegarde. Si une séquence de sauvegarde du journal est maintenue, la partie du journal avant le LSN minimum ne peut pas être réécrit tant les enregistrements du journal ne soient sauvegardés. Une fois qu'ils ont été sauvegardé, SQL Server peut utiliser le début du fichier. Voir la figure 5-3.

Figure 5-3. La portion active du journal.

Vous pouvez observer ce comportement avec un base d'exemple comme pubs, si vous n'avez pas encore réalisé de sauvegarde complète de la base. Si aucune modification n'a été faite sur la base pubs, la taille du journal des transaction est de 0.75 MB. Le prochain script créé une nouvelle table, insère trois enregistrements, et met à jour ces enregistrements 1000 fois. Chaque update est une transaction individuelle et est écrite au journal. Cependant, le journal ne grossit pas, même après 3000 mises à jour. (Si vous avez déjà fait une sauvegarde de la base, recréez la en lançant le script instpubs.sql dans le répertoire \mssql7\install.)

CREATE TABLE newtable ( a int) GO INSERT INTO newtable VALUES (10) INSERT INTO newtable VALUES (20) INSERT INTO newtable VALUES (30) GO DECLARE @counter int SET @counter = 1 WHILE @counter < 1000 BEGIN UPDATE newtable SET a = a + 1 SET @counter = @counter + 1 END

Faites maintenant une sauvegarde de la base pubs en vous assurant que l'option trunc. log on chkpt. n'est pas positionnée:

BACKUP DATABASE pubs to disk = 'c:\mssql7\backup\pubs.bak'

Relancez le script de modification des enregistrements une nouvelle fois à partir de DECLARE. Vous voyez que le fichier journal à augmenté. La taille initiale du journal ne peut pas être réutilisée car SQL Server déduit que vous avez sauvegardé ces informations pour des sauvegardes.

Maintenant vous pouvez essayer de réduire journal:

DBCC SHRINKDATABASE (pubs)

Ou si vous lancez une commande DBCC SHRINKFILE sur le fichier journal, SQL Server ne réduira pas le fichier journal tant que les enregistrements du journal ne sont sauvegardés ou que le journal soit tronqué. Vous pouvez tronquer le journal via:

BACKUP LOG pubs WITH TRUNCATE_ONLY

Vous remarquez que la taille du fichier journal a été réduite. Si un journal est réduit sans commande de réduction, SQL Server marque l'espace utilisé par les enregistrements tronqués comme candidat à la réutilisation, mais il ne change pas la taille du fichier.

Dans certaines conditions, les commandes précédentes ne réduisent pas le fichier journal. Cela survient si la partie active du journal est située à la fin du fichier. La réduction physique ne peut se faire que sur la fin du journal, et la partie active n'est jamais réduite. Pour remédier à cette situation, vous devez procéder en quatre étapes:

1. Assurez vous que les VLFs proches sont réutilisable en sauvegardant ou en tronquant le journal.
2. Exécutez une dizaine de mises à jour pour que le VLF actif bouge à un autre endroit.
3. Exécutez une commande DBCC SHRINKDATABASE.
4. Tronquez ou sauvegardez le journal une seconde fois pour forcer la réduction physique.

Si une base a l'option autoshrink activée, un processus autoshrink est démarré toutes les 30 minutes et détermine la taille à laquelle le journal doit être réduit. Le gestionnaire de journal accumule les statistiques sur une quantité maximum d'espace du journal dans ces intervalles. Le processus autoshrink positionne le point de réduction du journal à 125 pour-cent de l'espace maximum du journal utilisé, quelque soit sa grosseur. (la taille minimum est la taille de création du journal ou la taille à laquelle il a été diminué ou étendu.) Le journal sera réduit à cette taille, même tronqué ou sauvegardé. Il est possible d'avoir l'option autoshrink sans avoir trunc. log on chkpt., bien qu'il n'y a aucun moyen de garantir que le journal soit tronqué. (Si, par exemple, le journal n'est jamais sauvegardé, il ne sera jamais nettoyé.)