Récemment,  j’ai eu besoin de vider complètement le journal de transactions d’une base de données pour cause de manque de place disque disponible (disque taillé au plus juste comme d’habitude )

 

Quelques rappels sur la notion de “Recovery Model” (Mode de récupération en bon français)

La gestion du journal de transactions est en effet très liée au mode de récupération.

Les 2 modes possibles sont :

• Simple Recovery Model (simple) : Recycle automatiquement l’espace du journal afin de minimiser l’espace nécessaire. Dans ce mode et en cas de crash de la base, il n’est possible de récupérer les données que depuis la dernière sauvegarde.
• Full Recovery Model (complet) :  Exige des sauvegardes du journal. Dans ce mode, l’ensemble des transactions faites depuis la dernière sauvegarde sont conservées dans le journal. Ainsi, en cas de crash, il suffit de repartir de la dernière sauvegarde puis de rejouer l’ensemble des transactions pour retrouver la base dans son état d’origine

Plus de détails, sur cette page.

Purge du journal des transactions pour une base “Full Recovery model”

Si vous avez bien lu plus haut, vous avez deviné qu’il suffit d’effectuer une sauvegarde de la base et du journal de transactions pour le tronquer.

Purge du journal des transactions pour une base “Simple Recovery model”

D’après la documentation (du moins de ce que j’en ai compris) il n’y a normalement rien à faire pour gérer le journal, celui-ci s’auto-nettoie (telle une pyrolyse sur un four moderne).

L’expérience a montré que ce n’est pas complètement vrai. Dans mon cas, le problème s’est souvent produit lors de la restauration d’une base de données de production sur un environnement de développement (probablement lié au passage d’un mode “Full” à un mode “Simple” ?).

2 manipulations sont à tenter pour la purge :

1. Réduction de la taille du fichier journal par un DBCC SHRINKFILE
2. Suppression et recréation de ce fichier journal

Réduction de la taille du fichier journal par un DBCC SHRINKFILE

Tout d’abord il est nécessaire d’affichage l’occupation du journal des transactions par la commande suivante :

Qui va vous donner ce genre de sortie :

C’est la colonne “Log Space Used (%)” qui va nous intéresser : celle-ci nous donne le pourcentage d’espace occupé dans le journal des transactions. Un nombre proche de 100% signifie donc que le journal des transactions est quasiment plein et qu’il est temps de le vider un peu (sauf si vous avez activé l”autogrow” du journal, mais même dans ce cas, votre disque peut être taillé trop petit).

Ce vidage se fait via la commande :

En cas de doute, le nom du journal est peut être récupéré par la commande :

Il vous suffit ensuite de ré-exécuter un DBCC SQLPERF(logspace) pour s’assurer que de la place a été libérée.

Suppression et recréation de ce fichier journal

Dans le cas où la commande précédente a échoué, il reste la méthode dite “bourrin” : celle-ci consiste à recréer un journal de transactions de 0.

Toutes ces manipulations se font depuis “Sql Server Management Studio”

Pour cela il faut commencer par détacher la base de données (Bouton droit, “Propriétés” sur la base de données) :

Pensez à supprimer toutes les connections existantes :

Important : c’est ici, qu’il ne faut pas oublier de supprimer physiquement (ou de renommer au cas où) le fichier journal. Généralement le fichier s’appelle “base”_log.ldf.

Il faut ensuite ré-attacher la base (“joindre” en français) :

Sur l’écran suivant, cliquer sur “Ajouter”, choisir le fichier “mdf” correspondant à votre base.

Sélectionner ensuite le fichier journal puis cliquer sur “Supprimer”.

SqlServer ne trouvant pas le fichier journal, il le recrée de 0. Notez le résultat sur la dernière base de données avant / après :