web-dev-qa-db-fra.com

Réduire le journal des transactions lors de l'utilisation du groupe de disponibilité AlwaysOn

Nous utilisons la fonction AlwaysOn Availability Group De SQL Server 2012. Des sauvegardes complètes régulières de la base de données et des sauvegardes du journal des transactions sont effectuées tous les jours sur la base de données secondaire.

J'ai lu ici la sauvegarde du journal des transactions sur la réplique principale ou la réplique secondaire marquera les journaux de transactions des deux répliques comme réutilisables. Quoi qu'il en soit, la taille de la sauvegarde du journal des transactions est grande et peut être réduite à l'aide du fichier de réduction:

enter image description here

J'ai restauré la base de données localement et effectué l'opération de réduction. La taille du fichier journal a été réduite à 160 Mo.

Ma question est sur quelle base de données dois-je effectuer une opération de réduction sur le fichier journal des transactions (principal, secondaire ou les deux)?

Je suppose que dans le passé depuis plusieurs années, aucune sauvegarde du fichier journal n'est effectuée, il devient donc énorme. Exécution de DBCC SQLPERF (LOGSPACE) Je peux voir que seul 0.06% Du fichier est utilisé - il ne sert à rien de conserver une taille aussi énorme du fichier journal. Dans [sys].[database_files] Je vérifie que son max_size Est réglé sur -1 Avec growth à 65536 Donc je suppose que quand il aura besoin de plus d'espace il le fera avoir. Quoi qu'il en soit, je peux le réduire à 5% par exemple afin d'empêcher une croissance future. J'essaie de trouver une confirmation que ce n'est pas une mauvaise idée de le faire.

En fait, les sauvegardes (sur la base de données et les fichiers journaux) sont effectuées uniquement sur les bases de données secondaires, il sera donc plus facile d'effectuer le fichier de réduction sur celles-ci, mais la taille du fichier journal principal sera-t-elle également réduite?

sql-serversql-server-2012transaction-logshrink
17
gotqn

Dans les AG, les écritures ne peuvent avoir lieu que sur le primaire. Les opérations de rétrécissement sont des écritures. Par conséquent, vous devez effectuer la réduction sur le primaire. Notez que le rétrécissement peut ne pas rétrécir autant que prévu, votre test sur la base de données restaurée avait probablement utilisé un modèle de récupération simple. Lisez Comment réduire le journal SQL Server pour plus d'informations.

Ne rétrécissez pas à 160 Mo. Déterminez pourquoi le journal est-il passé à 121 Go afin qu'il ne se répète pas (vous avez des soupçons, ce serait bien de confirmer si possible). Dimensionnez le journal à une taille appropriée à vos besoins opérationnels. La croissance du journal est un problème grave, il ne peut pas utiliser l'initialisation instantanée des fichiers et toute votre activité de base de données se bloquera pendant que le journal grandit et est initialisé à 0. Les utilisateurs et les applications le détestent quand cela se produit. Si vous comprenez l'impact et que vos utilisateurs sont OK, vous pouvez réduire une fois à une petite quantité (160 Mo est probablement trop petit cependant) et laissez-le croître jusqu'à ce qu'il se stabilise.

21
Remus Rusanu

Tu peux essayer:

  1. La base de données sur tous les serveurs du groupe de disponibilité doit être à l'état synchronisé.
  2. Déplacez les pages utilisées pour démarrer le journal des transactions, avant de le réduire.
  3. Parfois, l'espace disponible du journal est de 99%, mais SQL Server ne peut pas libérer l'espace inutilisé. Essayez de redémarrer tour à tour chaque serveur du groupe de disponibilité.
  4. Parfois, vous devez créer et réduire le journal des transactions 2 fois avant que MS SQL Server ne libère de l'espace libre (Impossible de réduire le fichier journal (DB_Log) car le fichier journal logique situé à la fin du fichier est en cours d'utilisation.).

Essayez ce script:

 --Définir la base de données actuelle à l'intérieur de l'étape ou du script de tâche 
 --Vérifier Exécuter uniquement sur le primaire 
 Si (SELECT role 
 FROM sys.dm_hadr_available_replica_states AS a 
 REJOINDRE sys.availability_replicas AS b 
 ON b.replica_id = a.replica_id 
 OERE b.replica_server_name = @@ SERVERNAME) = 1 
 COMMENCER 
 - - Utiliser [test_db] - Ne fonctionne pas pour MS SQL 2014, il suffit de commenter cette ligne et de définir la base de données actuelle dans l'étape de travail ou le script 
 - 1) Bakup Trn 
 JOURNAL DE SAUVEGARDE [test_db] SUR DISQUE = N'D:\MSSQL\Backup\test_db.trn 'AVEC NOFORMAT, INIT, NAME = N' Trn Backup ', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10 
 - 2) Déplacer les pages utilisées 
 DBCC SHRINKFILE (N'test_db_log ', 3000, NOTRUNCATE) 
 - 3) SHRINKFILE Log 
 DBCC SHRINKFILE (N'test_db_log', 3000) 
 END
7
Denis P.