SQL Server sys.databases log_reuse_wait Frage

Question

Ich untersuchte das schnelle Wachstum eines SQL Server 2005-Transaktionsprotokolls, wenn ich feststellte, dass Transaktionsprotokolle nur korrekt abgeschnitten werden - wenn die Spalte "log_reuse_wait" der sys.databases auf 0 gesetzt ist Nichts hält das Transaktionsprotokoll davon ab, vorhandenen Speicherplatz wiederzuverwenden.

Eines Tages, als ich eine Protokolldatei sichern/abschneiden wollte, fand ich, dass diese Spalte eine 4 oder ACTIVE_TRANSACTION in der Tempdb hatte. Ich überprüft dann auf alle offenen Transaktionen, die DBCC OPENTRAN ('tempdb') und die open_tran-Spalte von Sysprocesses verwenden. Das Ergebnis war, dass ich nirgendwo im System aktive Transaktionen finden konnte.

Sind die Einstellungen in der Spalte log_reuse_wait korrekt? Gibt es Transaktionen, die mit den oben beschriebenen Methoden nicht nachweisbar sind? Fehle ich gerade etwas Offensichtliches?

Answer 1

Hm, knifflig. Könnte es sein, dass die Frage an sys.databases die ACTIVE_TRANSACTION verursacht? In diesem Fall sollte es jedoch in der MASTER und nicht in der TEMPDB sein.

Answer 2

Es gibt ein paar Links zu weiteren Tools/Referenzen Sie dieses Problem verwenden können, um die Fehlersuche bei den Referenzen für dieses Video verlinken:
Managing SQL Server 2005 and 2008 Log Files

Das heißt, sollten die Informationen in log_reuse_wait genau sein. Wahrscheinlich hatten Sie gerade eine blockierte oder verwaiste Transaktion, die Sie irgendwie nicht entdecken konnten.

Answer 3

My answer von The Log File for Database is Full:

Sobald Sie eine vollständige Sicherung der Datenbank übernehmen, und die Datenbank wird das einfache Wiederherstellungsmodell nicht verwenden, hält SQL Server eine vollständige Aufzeichnung aller Transaktionen je auf der Datenbank durchgeführt. Damit können Sie im Falle eines schwerwiegenden Fehlers, bei dem Sie die Datendatei verlieren, bis zur Fehlerquelle wiederherstellen, indem Sie das Protokoll sichern und nach Wiederherstellung einer alten Datensicherung das Protokoll wiederherstellen, um die verlorene Datei wiederzugeben Transaktionen.

Um dies zu verhindern, müssen Sie das Transaktionsprotokoll sichern. Oder Sie können die Kette am aktuellen Punkt unter Verwendung der TRUNCATE_ONLY oder NO_LOG Optionen von BACKUP LOG brechen.

Wenn Sie diese Funktion nicht benötigen, legen Sie das Wiederherstellungsmodell auf Simple fest.

Answer 4

Die Daten sind wahrscheinlich genau. Was Sie tun müssen, ist eine regelmäßige Transaktionsprotokollsicherung. Im Gegensatz zu anderen Ratschlägen sollten Sie die NO_TRUNCATE-Option für 2005 NICHT verwenden, da sie das Protokoll der Transaktionen löscht, aber nicht sichert.

Sie sollten eine Tail-Log-Sicherung durchführen, indem Sie die BACKUP LOG-Anweisung mit der Option NO_TRUNCATE verwenden. Sie sollten auch den gesamten Tag über regelmäßige Transaktionsprotokolle anlegen. Dies sollte helfen, die Größe überschaubar zu halten.

Answer 5

Ich weiß immer noch nicht, warum ich die ACTIVE_TRANSACTION in der Spalte log_reuse_wait_desc von sys.databases sah - wenn keine Transaktionen ausgeführt wurden, aber meine nachfolgende Erfahrung zeigt, dass sich die Spalte log_reuse_wait für die tempdb aus Gründen ändert, die nicht sehr sind klar und für meine Zwecke nicht sehr relevant.Auch fand ich, dass DBCC OPENTRAN ausgeführt wird, oder die „wählen open_tran aus sysprocess“ Code, viel weniger informativ als die folgenden Anweisungen verwenden, wenn Sie Transaktionsinformationen suchen:

select * from sys.dm_tran_active_transactions 

select * from sys.dm_tran_session_transactions 

select * from sys.dm_tran_locks 

Answer 6

Here gibt es Erklärungen, wie log_reuse_wait_desc arbeitet :

Wir müssen auch verstehen, wie der Log_reuse_wait_desc Berichtmechanismus funktioniert. Es gibt den Grund, warum die Protokollabschneidung beim letzten Versuch der Protokollabschneidung nicht auftreten konnte. Das kann verwirrend sein - wenn Sie beispielsweise ACTIVE_BACKUP_OR_RESTORE sehen und Sie wissen, dass kein Backup- oder Wiederherstellungsvorgang ausgeführt wird, bedeutet dies nur, dass beim letzten Versuch, das Abschneiden des Protokolls zu versuchen, eine ausgeführt wurde.

Also in Ihrem Fall gibt es derzeit keine ACTIVE TRANSACTION, aber es war, als letztes Mal versucht wurde, das Protokoll abzuschneiden.