Problème de Shrink du LOG

Bonjour,


un soucis au niveau du shrink de mon fichier de log (SQL 2005).

J'ai remarqué qu'il fallait que je fasse 2 fois un BACKUP LOG de ma base de données pour que je puisse après faire un shrink.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

-- Je pars avec un Fichier de log de 1 GO, avec 100% utilisé   BACKUP LOG ... -- Je suis toujours à 1 GO, mais avec seulement 2% utilisé : c'est normal   DBCC SHRINKDATABASE ... -- Je suis toujours à 1 GO, mais avec 2,5% utilisé : ????   BACKUP LOG xxxxx -- Je suis toujours à 1 GO, mais avec 1% utilisé : on a encore gagné 1.5 %   DBCC SHRINKDATABASE ... -- Je suis maintenant à 3 Mo, avec 30% utilisé : ????

---

Pourquoi dois-je faire une 2ème fois le backup log ?


merci de m'éclairer :cry:

Bonjour,

La commande SHRINKDATABASE réduit tous les fichiers de données et les journaux de transaction d'une base.

Si vous voulez simplement réduire simplement le journal de transaction (fichier log) utilisez la commande DBCC SHRINKFILE.

++

Bonjour,


merci de votre réponse.


C'est effectivement un SHRINKFILE que j'ai utilisé, je n'ai pas publié le bon code.

En tout état de cause, cla ne change rien à mon problème, j'ai bien dû exécuter la commande 2 fois.

Oui il est possible que vous ayez à opérer 2 fois une sauvegarde. En voici la raison :

Votre journal des transactions est composé de fichiers virtuels. Ceux-ci sont créés et gérés par SQL Server. Lorsque que vous sauvegardez votre journal, vous rendez inactifs les fichiers virtuels vides.

La commande DBCC SHRINFILE supprime ces fichiers virtuels inactifs.
La 1ère fois que vous exécutez cette commande il se peut que certains fichiers virtuels sont encore marqués comme actif et ne peuvent être supprimés.

Une 2ème sauvegarde marquera le reste des fichiers virtuels vides inactifs et la commande DBCC SHRINFILE pourra alors supprimer ces fichiers.

C'est la raison pour laquelle vous avez dû effectuer une 2ème sauvegarde avant que vous puissez réduire votre journal des transactions

++

Mike, merci de ces précisions.


Ce que ne comprend pas, c'est que après le 1er backup, SQL me dit que 98% du fichier est inutilisé ... Pourquoi le 1er SHRINK ne libère t'il pas ces 98 % ?

Y aurait-il encore une transaction active ancienne qui bloque la libération ? Auquel cas ça ne serait pas 98% du fichier de log considéré comme inactif (partie commitée antérieure à la transaction commitée la plus récente), mais 98% de transactions commitées et sauvegardée ?

J'ai ce soucis sur plusieurs bases.