Während meiner gesamten Karriere als Datenexperte, sowohl bei Microsoft als auch als Berater, habe ich festgestellt, dass einer der am meisten missverstandenen Teile einer SQL Server-Datenbank das Transaktionsprotokoll ist. Unwissenheit darüber, wie das Transaktionsprotokoll funktioniert und verwaltet werden muss, oder einfach nur Missverständnisse können zu allen Arten von Produktionsproblemen führen, darunter:
- Das Transaktionsprotokoll gerät außer Kontrolle und hat möglicherweise keinen Speicherplatz mehr
- Leistungsprobleme durch wiederholtes Verkleinern des Transaktionsprotokolls
- Leistungsprobleme aufgrund eines Problems, das als VLF-Fragmentierung bekannt ist , die ich in diesem Beitrag besprochen habe
- Die Unfähigkeit, mithilfe von Transaktionsprotokollsicherungen bis zu einem gewünschten Zeitpunkt wiederherzustellen
- Die Unfähigkeit, während der Notfallwiederherstellung eine Tail-Log-Sicherung durchzuführen (hier finden Sie eine Erläuterung zu Tail-Log-Sicherungen)
- Verschiedene Probleme bei Failover und Wiederherstellungsleistung
Mit diesem Beitrag starte ich eine gelegentliche Serie über das Transaktionsprotokoll und wie es funktioniert und verwaltet werden sollte, und ich werde im Laufe seines Verlaufs auf alle oben genannten Probleme eingehen. In diesem Beitrag erkläre ich, was Protokollierung ist und warum sie erforderlich ist.
Grundlegende Terminologie rund um die Protokollierung
Wenn ich über irgendeinen Mechanismus in SQL Server spreche, stelle ich fest, dass es ein Henne-Ei-Problem gibt, bei dem ich ein Wort oder einen Satz verwenden muss, bevor ich es erklärt habe. Um dieses Problem in dieser Serie zu vermeiden, werde ich damit beginnen, einige Terminologien zu erläutern, die verwendet werden müssen, wenn die Protokollierung diskutiert wird, und ich werde viele dieser Begriffe im Verlauf der Serie erweitern.
Transaktion, Commit und Rollback
Eine Transaktion umfasst eine Änderung oder eine Reihe von Änderungen an einer Datenbank. Es hat einen definierten Anfang und ein definiertes Ende. Der Anfang ist, wenn eine BEGIN TRANSACTION-Anweisung verwendet wird oder SQL Server automatisch eine Transaktion für Sie beginnt. Das Ende kann eines von vier Dingen sein:
- Die Transaktion wird festgeschrieben, wenn eine COMMIT TRANSACTION-Anweisung ausgeführt wird
- Die Transaktion wird festgeschrieben, wenn SQL Server die Transaktion im Falle einer Autocommit-Transaktion automatisch festschreibt
- Das Rollback der Transaktion wird beendet, nachdem eine ROLLBACK TRANSACTION-Anweisung ausgeführt wurde
- Das Rollback der Transaktion wird beendet, nachdem ein Problem aufgetreten ist, und SQL Server hat die Transaktion automatisch zurückgesetzt
Wenn eine Transaktion festgeschrieben wird, werden die von der Transaktion vorgenommenen Änderungen in der Datenbank abgeschlossen und im SQL Server-Transaktionsprotokoll auf dem Datenträger dauerhaft gespeichert. Beachten Sie, dass ich „im Transaktionsprotokoll“ gesagt habe. Die tatsächlichen Änderungen an den Datendateiseiten im Speicher werden *nicht* auf die Festplatte geschrieben, wenn die Transaktion festgeschrieben wird. Sie müssen in den Datendateien nicht dauerhaft gemacht werden, da die Änderungen bereits im Transaktionsprotokoll dauerhaft sind. Schließlich werden die Datendateiseiten durch eine Checkpoint-Operation auf die Festplatte geschrieben.
Umgekehrt sind beim Rollback einer Transaktion die Datenänderungen der Transaktion nicht mehr in der Datenbank vorhanden. Es wird immer noch einige physische Änderungen in der Datenbank geben, da das Zurücksetzen einer Transaktion bedeutet, dass mehr Änderungen vorgenommen werden, aber Sie können sich vorstellen, dass eine zurückgesetzte Transaktion die Daten in der Datenbank nicht beeinflusst hat.
Checkpoints und Rollback-Vorgänge sind Themen, die einen eigenen Beitrag verdienen, daher werde ich sie später in der Serie erläutern.
Auf diese drei Begriffe gehe ich im Tutorial Einführung in SQL Server-Transaktionen ausführlicher ein im SentryOne-Blog.
Protokollierung, Protokolldatensätze und das SQL Server-Transaktionsprotokoll
Protokollieren bedeutet einfach das Erstellen einer dauerhaften Beschreibung einer Änderung an einer Datenbank, fast immer im Zusammenhang mit einer Transaktion. Bei einer Änderung wird die Änderung in einem Protokollsatz beschrieben. Ein Protokolldatensatz enthält normalerweise genügend Informationen, damit die Änderung in der Datenbank wiedergegeben oder bei Bedarf in der Datenbank zurückgesetzt werden kann.
Dieser Protokolldatensatz befindet sich zunächst im Arbeitsspeicher und kann auf die Festplatte geschrieben werden, bevor die Transaktion festgeschrieben wird, muss aber unbedingt vorher auf die Festplatte geschrieben werden die Transaktion kann das Festschreiben abschließen, andernfalls wäre die Transaktion nicht dauerhaft. Eine Ausnahme von dieser Regel ist die verzögerte Haltbarkeit Funktion aktiviert ist, die Aaron Bertrand in diesem Beitrag bespricht.
Protokolldatensätze werden im Transaktionsprotokoll gespeichert (eine oder mehrere Protokolldateien auf der Festplatte), das eine etwas komplexe interne Architektur hat, und ich werde das und vieles mehr über Protokolldatensätze im nächsten Beitrag dieser Serie besprechen.
Absturzwiederherstellung
Bei einem Absturz wird SQL Server unerwartet heruntergefahren und die verschiedenen geänderten Datenbanken konnten nicht ordnungsgemäß heruntergefahren werden (stellen Sie sicher, dass alle geänderten Datendateiseiten auf die Festplatte geschrieben werden und die Datenbank als sauber heruntergefahren markiert ist).
Wenn SQL Server gestartet wird, überprüft es alle Datenbanken, um festzustellen, ob einige nicht als sauber heruntergefahren markiert wurden. Wenn es eine findet, muss diese Datenbank eine Wiederherstellung nach einem Absturz durchlaufen. Dadurch wird Folgendes sichergestellt:
- Stellen Sie bei allen Transaktionen, die vor dem Absturz festgeschrieben wurden, sicher, dass alle Änderungen in der Transaktion in der Datenbank widergespiegelt werden (d. h. wiederholen Sie die Transaktion)
- Stellen Sie bei allen Transaktionen, die vor dem Absturz nicht festgeschrieben wurden, sicher, dass keine der Änderungen in der Transaktion in der Datenbank widergespiegelt werden (d. h. setzen Sie die Transaktion zurück)
Mit anderen Worten, die Wiederherstellung nach einem Absturz macht eine Datenbank transaktionskonsistent zum Zeitpunkt des Absturzes. Absturzwiederherstellung wird verwendet:
- Wenn SQL Server startet und eine Datenbank findet, die wiederhergestellt werden muss
- Während eines Failovers auf eine sekundäre Kopie einer Datenbank
- Am Ende einer Wiederherstellungssequenz mit Sicherungen (siehe hier)
Die Wiederherstellung nach einem Absturz ist ein komplexer Prozess und erfordert einige weitere Posts in der Serie, bevor ich ihn ausführlich erläutern kann.
Warum ist eine Protokollierung erforderlich?
Der wichtigste Grund für die Protokollierung besteht darin, der SQL Server-Datenbank zu ermöglichen, Transaktionen dauerhaft zu machen, sodass sie während der Wiederherstellung nach einem Absturz wiederhergestellt oder bei Bedarf während des normalen Datenbankbetriebs zurückgesetzt werden können. Ohne Protokollierung wäre eine Datenbank nach einem Absturz transaktionsinkonsistent und möglicherweise strukturell beschädigt.
Ohne die Protokollierung wären jedoch eine Vielzahl anderer Funktionen in SQL Server nicht möglich, darunter:
- Datensicherungen, die konsistent wiederhergestellt werden können
- SQL Server-Transaktionsprotokollsicherungen, die während eines Wiederherstellungsvorgangs und zum Implementieren des Protokollversands verwendet werden können
- Replikation, die darauf beruht, dass Transaktionen aus dem Transaktionsprotokoll abgerufen werden können
- Change Data Capture, das den Protokollleseagenten für die Transaktionsreplikation verwendet, um Änderungen aus dem Transaktionsprotokoll zu erfassen
- Datenbankspiegelung und Verfügbarkeitsgruppen, die darauf angewiesen sind, Protokolldatensätze zur Wiedergabe an sekundäre Kopien der Datenbank zu senden
SQL Server (und alle ähnlichen Datenbankserver) verwenden das sogenannte Write-Ahead-Logging . Das bedeutet, dass die Beschreibungen der Änderungen vor den Änderungen selbst auf die Festplatte geschrieben werden müssen, um sicherzustellen, dass eine Datenbank ordnungsgemäß nach einem Absturz wiederhergestellt werden kann. Wenn eine Änderung in eine Datendatei geschrieben wurde, bevor die Protokolldatensätze sie beschreiben, und SQL Server abstürzt, gibt es keine Möglichkeit zu wissen, was rückgängig gemacht werden soll, und die Datenbank wäre inkonsistent. Diese Reihenfolge ist unveränderlich, unabhängig von der Isolationsstufe, der Art der Transaktion oder ob die verzögerte Dauerhaftigkeitsfunktion verwendet wird. Protokollaufzeichnungen zuerst, Datenseiten später.
Nur die Spitze des Eisbergs
Wie Sie in diesem Einführungsbeitrag sehen können, geht eine Menge in das Transaktionsprotokoll und die Protokollierung in einer SQL Server-Datenbank, und alles, was ich bisher getan habe, ist, einige allgemeine Terminologie zu definieren und zu erklären, warum die Protokollierung erforderlich ist. Ich hoffe, Sie schließen sich mir an, wenn ich mich verzweige und im Verlauf der Serie tiefer gehe!
