Ich würde mich zunächst auf die Einstellungen für das automatische Wachstum für die Datenbank konzentrieren, da zu häufiges und falsches automatisches Wachstum zu einer massiven internen Protokollfragmentierung führen kann, die sich auf alle Prozesse auswirkt, die Transaktionsprotokolldateien lesen (z. B. Replikation, CDC, Sicherungen usw.), und dadurch die Anzahl der VLFs erhöht . Denken Sie daran, dass die Protokolldatei wachsen muss, da sie nicht NULL initialisiert werden kann. Wenn die Einstellungen für das automatische Wachstum nicht geeignet sind, muss SQL Server warten, bis das Ereignis für das automatische Wachstum abgeschlossen ist.
Wenn Sie jetzt T-Rep verwenden, liest der Protokollleser-Agent das Protokoll, wenn Änderungen vom Herausgeber an den Distributor repliziert werden, und der Distributor-Agent verteilt die Änderungen an die Abonnenten, die als "ausstehende Transaktionen" bezeichnet werden. Sobald die Änderungen repliziert wurden, wird der Protokolleintrag als "repliziert" markiert.
Das Problem tritt auf, wenn der Protokollleser langsam wird oder sich verzögert, was dazu führt, dass sich über lange Zeiträume "ausstehende Replikations" -Befehle ansammeln und diese Teil des aktiven Protokolls bleiben und daher VLF nicht abgeschnitten werden kann.
Sie können die Spalte log_reuse_wait_desc in sys.databases überprüfen, in der "Replikation" als Problem angezeigt wird.
Hinweis: Die Zusammenführungsreplikation und die Snapshot-Replikation wirken sich nicht auf die Größe des Transaktionsprotokolls aus. Wenn eine Datenbank eine oder mehrere Transaktionspublikationen enthält, wird das Protokoll erst abgeschnitten, wenn alle für die Veröffentlichungen relevanten Transaktionen an die Verteilungsdatenbank übermittelt wurden.
Wenn die Protokolldatei außer Kontrolle gerät, besteht eine übliche Technik für T-Rep darin, den Befehl sp_repldone zu verwenden, um alle derzeit auf dem Protokollleser wartenden Protokolldatensätze als repliziert zu markieren. Anschließend müssen Sie die Abonnenten neu initialisieren .
Hinweis: Selbst wenn Sie versuchen, zu einem einfachen Wiederherstellungsmodell zu wechseln, bei dem angenommen wird, dass das Protokoll abgeschnitten wird, funktioniert es nicht, da die Replikation auch bei der EINFACHEN Wiederherstellung unterstützt wird und das Protokoll nicht abgeschnitten werden kann, da der Protokollleser-Agent sie benötigt herstellen.
Dies führt uns zu einer ordnungsgemäßen Protokollverwaltung - Größe der Protokolldatei, um das Volumen der in der Datenbank auftretenden Datenänderungen zu unterstützen, und häufige Protokollsicherungen, um eine schnelle Wiederverwendung des Speicherplatzes in der Protokolldatei zu ermöglichen.
Am besten ist es zu überwachen Ihr Transaktionsprotokoll zusammen mit anderen Monitoring , dass Sie vielleicht normalerweise tun , die mit PERFMON und DMV.
Nur zu Ihrer Information, sys.dm_db_log_space_usage ist eine neue DMV in SQL Server 2012, die grundlegende Informationen zu Protokollgröße und Speicherplatz erhält.
Verweise :