Impossible de réduire le fichier journal des transactions dans SQL Server
J'ai récemment déménagé dans une nouvelle entreprise dans laquelle ils ont 2 bases de données dans un serveur SQL de taille 20-25 Go. Je ne parviens pas à réduire le fichier journal des bases de données.
La sauvegarde du journal des transactions des bases de données est configurée pour s'exécuter toutes les 30 minutes de 6 h à 19 h.
Ils sont respectivement de taille 10 et 2 Go.
J'ai essayé de le réduire autour de 8-9 PM hier soir mais je n'ai pas pu le faire.
La colonne log_reuse_wait a indiqué qu'elle attendait une sauvegarde log_backup.
J'ai essayé de faire quelques sauvegardes de journaux, ce qui n'a pas aidé.
J'ai exécuté DBCC OPENTRAN mais il n'y a aucune transaction en cours.
De plus, ce matin, même après le démarrage des sauvegardes Tlog à 6 h 00 (10 h 30), il affiche toujours LOG_BACKUP dans la colonne log_reuse_wait.
Et pas d'OPEN TRAN également.
Lorsque j'ai fait des recherches à ce sujet, j'ai trouvé cet article de Paul Randal: http://www.sqlskills.com/blogs/paul/why-is-log_reuse_wait_desc-saying-log_backup-after-doing-a-log-backup /
Il indique que si la base de données est petite et que tout le contenu du fichier tlog est dans le même VLF il ne pourrait pas être tronqué.
J'ai environ 300 à 400 VLF dans les bases de données.
Donc cela n'a pas de sens ici aussi.
Une chose que j'ai remarquée, c'est que chaque matin à 6 heures du matin, le journal est un peu plus gros que les autres.
Je pense donc à vérifier auprès du DBA principal pour exécuter tlog 24 heures sur 24.
En dehors de cela, je voudrais voir pourquoi cela se produit et est-ce que je manque quelque chose.
J'ai essayé de rétrécir avec la commande ci-dessous:
Use DB1
go
DBCC SHRINKFILE(2,10)
GO
Remarque: il s'agit d'une instance SQL 2012 exécutant la compatibilité 0n 2012
La raison pour laquelle votre processus ne fonctionne pas est qu'il attend de libérer la partie inactive du journal à l'aide d'une sauvegarde du journal des transactions. Le passage au modèle de récupération simple contourne ce problème.
Si vous avez vraiment besoin de réduire le journal des transactions, afin de pouvoir le repousser (pour réduire le nombre de VLF, par exemple), voici le processus:
1) Passer au modèle de récupération simple
2) Exécutez un CHECKPOINT et DBCC DROPCLEANBUFFERS (juste au cas où)
3) Réduisez le fichier journal
4) Revenez au modèle de récupération complète
5) Augmentez le journal par incréments raisonnables (j'utilise des incréments de 4000 Mo)
6) Définissez la croissance automatique sur une valeur que votre sous-système d'E/S peut gérer
7) Exécutez une sauvegarde complète ou différentielle pour redémarrer la chaîne de sauvegarde des journaux.
Il semble que vous ayez juste besoin de continuer à exécuter les sauvegardes du journal des transactions pendant la nuit. Peut-être pas toutes les 30 minutes comme pendant la journée, mais une fenêtre de 11 heures sans sauvegarde des journaux de transfert est probablement votre problème ici.
Même si l'activité réelle tilisateur est faible, toute autre activité se produisant la nuit augmentera le journal des transactions. Par exemple: maintenance de base de données (comme la réindexation), processus ETL (nouvelles importations de données, archivage/suppression de données, mises à jour à partir d'autres systèmes, calculs nocturnes, etc.).
Personnellement, pour une base de données de 20 à 25 Go, je serais totalement à l'aise avec le journal des transactions n'importe où dans la plage de ~ 1 Go à ~ 10 Go, selon le niveau d'activité. Je ne sais pas pourquoi vous pensez que 2 Go est si gros. C'est travail de l'espace pour le moteur SQL, pas du gaspillage.
Si vous souhaitez réduire le plus grand, voici ma recommandation pour réduire un journal en mode de récupération complète:
- Exécutez le travail de sauvegarde du journal des transactions (ou autorisez-le à s'exécuter dans les délais).
- Faites une
SHRINKFILE (name='mylog',size=4000)avec une taille cible spécifique. - Exécutez à nouveau immédiatement le travail de sauvegarde du journal des transactions.
- Répétez immédiatement le
SHRINKFILE.
À l'exception des bases de données avec des transactions ouvertes extrêmement longues, cela n'a jamais manqué de me permettre de réduire le fichier.
Même après avoir changé le modèle de récupération pour vérifier simplement s'il y avait un verrou sur l'objet propre à la base de données pour laquelle vous souhaitez réduire le fichier journal, j'ai un problème similaire qui ne peut pas réduire le fichier journal même après avoir changé le modèle de récupération simple, une fois que je relâchez le verrou, j'ai pu réduire le fichier journal.