Verkleinern des Transaktionsprotokolls bei Verwendung der AlwaysOn-Verfügbarkeitsgruppe

Wir verwenden die AlwaysOn Availability GroupFunktion von SQL Server 2012. Regelmäßige vollständige Datenbank- und Transaktionsprotokollsicherungen werden täglich in der sekundären Datenbank durchgeführt.

Ich habe hier gelesen , dass das Durchführen der Transaktionsprotokollsicherung entweder auf dem primären oder dem sekundären Replikat die Transaktionsprotokolle beider Replikate als wiederverwendbar markiert. Wie auch immer, die Sicherungsgröße des Transaktionsprotokolls ist groß und kann mithilfe der Datei verkleinert werden:

Ich habe die Datenbank lokal wiederhergestellt und den Verkleinerungsvorgang ausgeführt. Die Größe der Protokolldatei wurde auf 160 MB reduziert.

Meine Frage ist, auf welcher Datenbank ich einen Verkleinerungsvorgang über die Transaktionsprotokolldatei (primär, sekundär oder beides) ausführen soll.

Ich denke, in der Vergangenheit wurden seit einigen Jahren keine Backups der Protokolldatei erstellt, so dass sie so umfangreich geworden ist. Beim Ausführen DBCC SQLPERF (LOGSPACE)kann ich feststellen, dass nur 0.06%die Datei verwendet wird. Es hat keinen Sinn, die Protokolldatei so groß zu halten. In [sys].[database_files]überprüfe ich, ob max_sizees auf -1mit gesetzt ist growth, 65536damit ich schätze, wenn es mehr Platz braucht, wird es bekommen. Jedenfalls kann ich es auf 5% reduzieren, um zukünftiges Wachstum zu verhindern. Ich versuche eine Bestätigung zu finden, dass es keine schlechte Idee ist, dies zu tun.

Eigentlich werden Sicherungen (in der Datenbank und in den Protokolldateien) nur in den sekundären Datenbanken ausgeführt, sodass die Verkleinerungsdatei einfacher ausgeführt werden kann. Wird jedoch auch die Größe der primären Protokolldatei verringert?

Bei AGs können Schreibvorgänge nur auf dem primären erfolgen. Verkleinerungsoperationen werden geschrieben. Daher müssen Sie den Schrumpfvorgang auf der Primärseite durchführen. Beachten Sie, dass der Verkleinerungsfaktor möglicherweise nicht so stark wie erwartet verkleinert wird. Bei Ihrem Test für die wiederhergestellte Datenbank wurde wahrscheinlich ein einfaches Wiederherstellungsmodell verwendet. Weitere Informationen finden Sie unter So verkleinern Sie das SQL Server-Protokoll .

Schrumpfen Sie nicht auf 160 MB. Bestimmen Sie, warum hat das Protokoll zu 121Gb wachsen , damit es nicht wiederholen wird (Sie den Verdacht haben, wäre schön zu bestätigen , wenn möglich). Passen Sie die Größe des Protokolls an Ihre betrieblichen Anforderungen an. Das Protokollwachstum ist ein ernstes Problem. Es kann keine sofortige Dateiinitialisierung verwenden, und Ihre gesamte Datenbankaktivität wird eingefroren, während das Protokoll wächst und mit 0 initialisiert wird. Benutzer und Apps hassen es, wenn es auftritt. Wenn Sie die Auswirkungen verstehen und Ihre Benutzer in Ordnung sind, können Sie einmal auf einen kleinen Wert (160 MB sind jedoch wahrscheinlich zu klein) verkleinern und ihn wachsen lassen, bis er sich stabilisiert.

Du kannst es versuchen:

1. Die Datenbank auf allen Servern in der Verfügbarkeitsgruppe sollte synchronisiert sein.
2. Verschieben Sie die verwendeten Seiten an den Anfang des Transaktionsprotokolls, bevor Sie es verkleinern.
3. Manchmal beträgt der verfügbare freie Speicherplatz des Protokolls 99%, SQL Server kann jedoch nicht verwendeten Speicherplatz nicht freigeben. Versuchen Sie, jeden Server in der Verfügbarkeitsgruppe nacheinander neu zu starten.
4. Manchmal müssen Sie das Transaktionsprotokoll zwei Mal sichern und verkleinern, bevor MS SQL Server freien Speicherplatz freigibt (Protokolldatei (DB_Log) kann nicht verkleinert werden, da die logische Protokolldatei am Ende der Datei verwendet wird.).

Versuchen Sie dieses Skript:

    --Stellen Sie die aktuelle Datenbank im Jobschritt oder im Skript ein
    --Überprüfen Sie, ob die Ausführung nur auf Primärbasis erfolgt
    if (Rolle AUSWÄHLEN
        FROM sys.dm_hadr_availability_replica_states AS a
        JOIN sys.availability_replicas AS b
            ON b.replica_id = a.replica_id
    WO b.replica_server_name = @@ SERVERNAME) = 1
    START
        - Verwenden Sie [test_db]. - Funktioniert nicht für MS SQL 2014, kommentieren Sie diese Zeile und setzen Sie die aktuelle Datenbank innerhalb des Auftragsschritts oder Skripts
        - 1) Bakup Trn
        BACKUP LOG [test_db] TO DISK = N'D: \ MSSQL \ Backup \ test_db.trn 'MIT NOFORMAT, INIT, NAME = N' Trn Backup ', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10
        - 2) Verschieben Sie die verwendeten Seiten
        DBCC SHRINKFILE (N'test_db_log ', 3000, NOTRUNCATE)
        - 3) SHRINKFILE-Protokoll
        DBCC SHRINKFILE (N'test_db_log ', 3000)
    ENDE