Im zweiten Teil dieser Serie habe ich die strukturelle Hierarchie des Transaktionsprotokolls beschrieben. Da sich dieser Beitrag hauptsächlich mit den von mir beschriebenen Virtual Log Files (VLFs) befasst, empfehle ich Ihnen, den zweiten Teil zu lesen, bevor Sie fortfahren.
Wenn alles in Ordnung ist, wird das Transaktionsprotokoll in einer Endlosschleife ausgeführt, wobei die vorhandenen VLFs wiederverwendet werden. Dieses Verhalten nenne ich die zirkuläre Natur des Protokolls . Manchmal passiert jedoch etwas, um dies zu verhindern, und das Transaktionsprotokoll wächst und wächst und fügt immer mehr VLFs hinzu. In diesem Beitrag erkläre ich, wie das alles funktioniert oder manchmal auch nicht.
VLFs und Protokollkürzung
Alle VLFs haben eine Header-Struktur, die Metadaten über das VLF enthält. Eines der wichtigsten Felder in der Struktur ist der Status des VLF, und die Werte, an denen wir interessiert sind, sind Null, was bedeutet, dass das VLF inaktiv ist , und zwei, was bedeutet, dass das VLF aktiv ist . Dies ist wichtig, da ein inaktiver VLF wiederverwendet werden kann, ein aktiver jedoch nicht. Beachten Sie, dass ein VLF vollständig aktiv oder vollständig inaktiv ist.
Ein VLF bleibt aktiv, solange die erforderlichen Protokolldatensätze darin enthalten sind, sodass es nicht wiederverwendet und überschrieben werden kann (ich werde das nächste Mal auf die Protokolldatensätze selbst eingehen). Beispiele für Gründe, warum Protokollaufzeichnungen erforderlich sein können, sind:
- Es gibt eine lange laufende Transaktion, zu der die Protokolldatensätze gehören, daher können sie nicht freigegeben werden, bis die Transaktion festgeschrieben oder das Rollback abgeschlossen ist
- Eine Protokollsicherung hat diese Protokolldatensätze noch nicht gesichert
- Dieser Teil des Protokolls wurde noch nicht vom Protokolllese-Agent für die Transaktionsreplikation oder die Datenänderungserfassung verarbeitet
- Dieser Teil des Protokolls wurde noch nicht an eine asynchrone Datenbankspiegelung oder ein Verfügbarkeitsgruppenreplikat gesendet
Es ist wichtig zu beachten, dass, wenn es keinen Grund dafür gibt, dass ein VLF aktiv bleibt, es nicht wieder inaktiv wird, bis ein Prozess namens Protokollkürzung stattfindet auftritt – dazu weiter unten mehr.
Unter Verwendung eines einfachen hypothetischen Transaktionsprotokolls mit nur fünf VLFs und VLF-Sequenznummern beginnend bei 1 (erinnern Sie sich vom letzten Mal, dass dies in Wirklichkeit nie der Fall ist), wenn das Transaktionsprotokoll erstellt wird, wird VFL 1 sofort als aktiv markiert, wie es immer der Fall war mindestens ein aktives VLF im Transaktionsprotokoll sein – das VLF, in das derzeit Protokollblöcke geschrieben werden. Unser Beispielszenario ist in Abbildung 1 unten dargestellt.
Abbildung 1:Hypothetisches, brandneues Transaktionsprotokoll mit 5 VLFs, Sequenznummern 1 bis 5.
Wenn mehr Protokolldatensätze erstellt und weitere Protokollblöcke in das Transaktionsprotokoll geschrieben werden, füllt sich VLF 1, sodass VLF 2 aktiv werden muss, damit mehr Protokollblöcke geschrieben werden können, wie in Abbildung 2 unten gezeigt.
Abbildung 2:Aktivität bewegt sich durch das Transaktionsprotokoll.
SQL Server verfolgt den Start der ältesten nicht festgeschriebenen (aktiven) Transaktion, und diese LSN wird bei jedem Prüfpunktvorgang auf dem Datenträger beibehalten. Die LSN des letzten Protokolleintrags, der in das Transaktionsprotokoll geschrieben wurde, wird ebenfalls nachverfolgt, aber nur im Speicher, da es keine Möglichkeit gibt, ihn auf der Festplatte zu speichern, ohne auf verschiedene Race-Bedingungen zu stoßen. Das spielt keine Rolle, da es nur während der Wiederherstellung nach einem Absturz verwendet wird und SQL Server die LSN des „Endes“ des Transaktionsprotokolls während der Wiederherstellung nach einem Absturz ermitteln kann. Checkpoints und Wiederherstellung nach einem Absturz sind Themen für zukünftige Posts in dieser Serie.
Schließlich füllt sich VLF 2 und VLF 3 wird aktiv und so weiter. Der springende Punkt bei der zirkulären Natur des Transaktionsprotokolls ist, dass frühere VLFs im Transaktionsprotokoll inaktiv werden, sodass sie wiederverwendet werden können. Dies geschieht durch einen Prozess namens Protokollkürzung , was allgemein auch als Protokolllöschung bezeichnet wird . Leider sind diese beiden Begriffe schreckliche Fehlbezeichnungen, da nichts wirklich abgeschnitten oder gelöscht wird.
Das Abschneiden des Protokolls ist einfach der Prozess, alle VLFs im Transaktionsprotokoll zu untersuchen und zu bestimmen, welche aktiven VLFs jetzt wieder als inaktiv markiert werden können, da keiner ihrer Inhalte mehr von SQL Server benötigt wird. Wenn eine Protokollkürzung durchgeführt wird, gibt es keine Garantie dafür, dass aktive VLFs inaktiv gemacht werden können – es hängt ganz davon ab, was mit der Datenbank passiert.
Es gibt zwei häufige Missverständnisse bezüglich der Protokollkürzung:
- Das Transaktionsprotokoll wird kleiner (das „Abschneiden“-Missverständnis). Nein, tut es nicht – es gibt keine Größenänderung durch das Abschneiden von Protokollen. Das einzige, was das Transaktionslog verkleinern kann, ist eine explizite DBCC SHRINKFILE.
- Die inaktiven VLFs werden auf irgendeine Weise auf Null gesetzt (das Missverständnis des „Löschens“). Nein – außer einigen Feldern im VLF-Header wird nichts in das VLF geschrieben, wenn es deaktiviert wird.
Abbildung 3 unten zeigt unser Transaktionsprotokoll, in dem die VLFs 3 und 4 aktiv sind und die Protokollkürzung die VLFs 1 und 2 als inaktiv markieren konnte.
Abbildung 3:Protokollkürzung markiert frühere VLFs als inaktiv.
Wann das Protokoll abgeschnitten wird, hängt davon ab, welches Wiederherstellungsmodell für die Datenbank verwendet wird:
- Einfaches Modell:Protokollkürzung erfolgt, wenn eine Checkpoint-Operation abgeschlossen ist
- Vollständiges Modell oder massenprotokolliertes Modell:Die Protokollkürzung erfolgt, wenn eine Protokollsicherung abgeschlossen ist (solange keine gleichzeitige vollständige oder differenzielle Sicherung ausgeführt wird; in diesem Fall wird die Protokollkürzung verschoben, bis die Datensicherung abgeschlossen ist)
Davon gibt es keine Ausnahmen.
Kreisförmige Natur des Protokolls
Um zu vermeiden, dass das Transaktionsprotokoll wachsen muss, muss die Protokollkürzung in der Lage sein, VLFs als inaktiv zu markieren. Das erste physische VLF im Protokoll muss inaktiv sein, damit das Transaktionsprotokoll seinen Zirkelcharakter hat.
Betrachten Sie Abbildung 4 unten, die zeigt, dass die VLFs 4 und 5 verwendet werden und die Protokollkürzung die VLFs 1 bis 3 als inaktiv markiert hat. Es werden mehr Protokolldatensätze generiert, mehr Protokollblöcke werden in VLF 5 geschrieben und schließlich füllt es sich.
Abbildung 4:Aktivität füllt die höchste physische VLF im Transaktionsprotokoll.
An diesem Punkt prüft der Protokollmanager für die Datenbank den Status des ersten physischen VLF im Transaktionsprotokoll, das in unserem Beispiel VLF 1 mit der Sequenznummer 1 ist. VLF 1 ist inaktiv, sodass das Transaktionsprotokoll umlaufen kann Beginnen Sie wieder von vorne mit dem Füllen. Der Protokollmanager ändert das erste VLF in aktiv und erhöht seine Sequenznummer um eins höher als die aktuell höchste VLF-Sequenznummer. Es wird also zu VLF 6, und die Protokollierung wird fortgesetzt, wobei der Protokollblock in dieses VLF geschrieben wird. Dies ist die kreisförmige Natur des Protokolls, wie unten in Abbildung 5 gezeigt.
Abbildung 5:Die kreisförmige Natur des Transaktionsprotokolls und der VLF-Wiederverwendung.
Wenn etwas schief geht
Wenn das erste physische VLF im Transaktionsprotokoll nicht inaktiv ist, kann das Transaktionsprotokoll nicht umlaufen, sodass es wächst (sofern es so konfiguriert ist und ausreichend Speicherplatz vorhanden ist). Dies geschieht häufig, weil etwas verhindert, dass die Protokollkürzung VLFs deaktiviert. Wenn Sie feststellen, dass das Transaktionsprotokoll für eine Datenbank wächst, können Sie SQL Server abfragen, um herauszufinden, ob ein Problem beim Abschneiden des Protokolls vorliegt, indem Sie den folgenden einfachen Code verwenden:
SELECT
[log_reuse_wait_desc]
FROM [master].[sys].[databases]
WHERE [name] = N'MyDatabase'; Wenn die Protokollkürzung ein oder mehrere VLFs deaktivieren konnte, ist das Ergebnis NOTHING. Sonst , erhalten Sie einen Grund, warum die Protokollkürzung keine VLFs deaktivieren konnte. Es gibt eine lange Liste möglicher Gründe, die hier im Abschnitt Faktoren, die das Abschneiden von Protokollen verzögern können. beschrieben werden
Es ist wichtig, die Semantik des Ergebnisses zu verstehen:Es ist der Grund, warum die Protokollkürzung beim letzten Ausführungsversuch nichts bewirken konnte . Das Ergebnis könnte beispielsweise ACTIVE_BACKUP_OR_RESTORE, sein aber Sie wissen, dass diese lang andauernde vollständige Sicherung abgeschlossen ist. Dies bedeutet lediglich, dass das Backup noch ausgeführt wurde, als das letzte Mal versucht wurde, das Protokoll zu kürzen.
Meiner Erfahrung nach ist LOG_BACKUP der häufigste Grund dafür, dass das Abschneiden von Protokollen verhindert wird; d.h. führen Sie eine Protokollsicherung durch! Aber es gibt auch ein interessantes, seltsames Verhalten bei LOG_BACKUP . Wenn Sie ständig das Ergebnis LOG_BACKUP sehen Sie wissen jedoch, dass Protokollsicherungen erfolgreich durchgeführt werden, weil in der Datenbank sehr wenig Aktivität stattfindet und die aktuelle VLF dieselbe ist wie beim letzten Mal, als eine Protokollsicherung durchgeführt wurde. Also LOG_BACKUP bedeutet „Gehe und führe eine Log-Sicherung durch“ oder „Alle gesicherten Log-Einträge stammen von der aktuellen VLF, daher konnte sie nicht deaktiviert werden.“ Wenn letzteres passiert, kann es verwirrend sein.
Umkreisen zurück…
Es ist sehr wichtig, den zirkulären Charakter des Transaktionsprotokolls aufrechtzuerhalten, um kostspieliges Wachstum des Protokolls und die Notwendigkeit von Korrekturmaßnahmen zu vermeiden. Normalerweise bedeutet dies, sicherzustellen, dass Protokollsicherungen regelmäßig durchgeführt werden, um das Abschneiden von Protokollen zu erleichtern, und das Transaktionsprotokoll so zu dimensionieren, dass es alle großen, lang andauernden Vorgänge wie Indexwiederherstellungen oder ETL-Vorgänge aufnehmen kann, ohne dass ein Protokollwachstum auftritt.
Im nächsten Teil der Serie werde ich Protokollaufzeichnungen, ihre Funktionsweise und einige interessante Beispiele behandeln.
