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

Nous utilisons la AlwaysOn Availability Groupfonctionnalité 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 que 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:

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. En exécutant, DBCC SQLPERF (LOGSPACE)je peux voir que seul 0.06%le fichier est utilisé - il ne sert à rien de garder une taille aussi énorme du fichier journal. Dans [sys].[database_files]Je vérifie que son max_sizeest réglé -1avec growthpour 65536donc je suppose que quand il a besoin de plus d' espace , il obtiendra. 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?

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 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 l'activité de votre base de données se bloquera pendant que le journal se développe 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 vont bien, vous pouvez réduire une fois une petite quantité (160 Mo est probablement trop petit cependant) et le laisser croître jusqu'à ce qu'il se stabilise.

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 libre 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 de travail ou du script
    --Vérifiez l'exécution sur le primaire uniquement
    if (SELECT role
        FROM sys.dm_hadr_availability_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) Journal SHRINKFILE
        DBCC SHRINKFILE (N'test_db_log ', 3000)
    FIN