Jede SQL Server Datenbank wird über mehrere Dateien im Dateisystem abgelegt. Diese Dateien speichern sowohl Daten als auch Transaktionsprotokolleinträge. Jede Datenbank hat ihren eigenen Satz an Dateien. Die Datenbankdaten werden in MDF Dateien und die Transaktionsprotokolldaten werden in komplett getrennten LDF Dateien gehalten. Rein konzeptionell werden die Transaktionen als eine Kette von Protokolleinträge abgelegt. Diese Einträge werden in eine bzw. mehrere physische LDF-Dateien gespeichert.
Der primäre Zweck einer LDF-Datei ist es, die AKID-Eigenschaften (Atomarität, Konsistenz, Isolation und Dauerhaftigkeit) zu ermöglichen:
- Atomarität: Wenn ein Teil einer Transaktion fehlschlägt, schlägt die gesamte Transaktion fehl und die Datenbank bleibt unverändert
- Konsistenz: Jede Transaktion hinterlässt die Datenbank in einem konsistenten Zustand
- Isolation: Die Ausführung von gleichzeitigen Transaktionen verändert die Datenbank als wären die Transaktionen seriell abgearbeitet worden. Das heißt, die parallelen Ausführungen haben gegenseitig keinen Einfluss auf die Ausführung der anderen Transaktionen
- Dauerhaftigkeit: Sobald eine Transaktion abgeschlossen wurde, bleiben die darin enthaltenen Änderungen dauerhaft gespeichert – selbst, wenn andere Fehler auftreten, wie z.B. Stromausfall
Eine LDF-Datei speichert genug Informationen, um eine Änderung neu durchzuführen oder zurückzusetzen. Deshalb kommt es oft vor, dass die LDF-Datei untersucht werden muss, um Wiederherstellungsarbeiten zu ermöglichen oder Auditierungen durchzuführen. Das reine Auslesen einer LDF-Datei ist allerdings nicht sehr einfach.
Es gibt mehrere SQL Server-Funktionen und -Befehle (z.B. fn_dblog, fn_dump_dblog und DBCC PAGE), die bestimmte Informationen aus einer LDF-Datei laden können, dennoch benötigen Sie sehr spezielles Wissen, das zudem teilweise nicht offiziell dokumentiert bzw. unterstützt ist und Ergebnisse liefert, die nicht sehr einfach zu lesen sind.
Hier zeigen wir ein paar Beispiel-Ergebnisse dieser Befehle und Funktionen:
-
Hier sehen wir die Ausgabe von “fn_dblog”. Es werden insgesamt 129 Spalten aus einer gerade in Benutzung befindlichen LDF-Datei geladen
-
Hier sehen wir die Ausgabe von “fn_dump_dblog”. Diese Funktion liefert Daten aus Transaktionsprotokollsicherungen (sowohl komprimiert als auch unkomprimiert). Die Ergebnisse ähneln denen von “fn_dblog”
Leider gibt es keine offizielle Dokumentation für diese Funktionen. Um die Ergebnisse richtig zu interpretieren, müssen Sie die Struktur, Formate und Statusfelder kennen
-
“DBCC PAGE” liefert die Inhalte aus MDF und LDF Dateien in Form eines Binärstroms. Diese Informationen zu entziffern ist noch schwieriger
Verwendung von “ApexSQL Log” um eine LDF-Datei auszulesen
ApexSQL Log ist eine Applikation um Transaktionsprotokolldateien auszulesen. Es können in Benutzung befindliche Dateien sowie Sicherungsdateien (ob native Sicherungen oder komprimierte Sicherungen) ausgelesen werden. ApexSQL ist darauf spezialisiert, Operationen (DML und DDL) sowie die tatsächlichen Änderungen auszulesen.
Neben der Fähigkeit die Dateiinhalte darzustellen, kann ApexSQL Log u.a. Skripte erstellen, um Änderungen rückgängig zu machen und erneut durchzuführen sowie eine Änderungshistorie für Datensätze erzeugen.
So öffnet und liest ApexSQL Log eine LDF Datei:
-
Verbinden Sie sich mit der Datenbank, die ausgelesen werden soll:
-
Nun müssen alle dazugehörigen Sicherungsdateien und/oder abgekoppelte LDF-Dateien hinzugefügt werden. Sorgen Sie dafür, dass sie alle Protokolle und Sicherungen auswählen, die zu einer Protokollkette gehören. Eine Protokollkette ist eine lückenlose Kette von Protokollsicherungen, die mit einer Komplettsicherung der Datenbank anfängt, gefolgt von allen anschließenden Protokollsicherungen bis zum gewünschten Wiederherstellungszeitpunkt. Wurde diese Kette unterbrochen, können Sie sie nur bis zur letzten erfolgreichen Protokollsicherung wiederherstellen.
Anders als INSERT- und DELETE-Befehle, die komplett protokolliert werden, werden UPDATE-Befehle anders gespeichert. Bei UPDATEs werden nur die Änderungen gespeichert und nicht die alten und neuen Werte (z.B. SQL Server schreibt, dass “R” in “L” geändert wurde, wenn eigentlich “GRAS” in “GLAS” geändert wurde). Diese “minimale Protokollierung” reicht aus, um die Prinzipien von AKID gerecht zu werden, allerdings ist es schwieriger, diese Änderung zu rekonstruieren.
Um die Änderungsschritte komplett darzustellen, muss ApexSQL Log gleich mehrere Methoden verwenden. Eine diese Methoden ist es, die komplette Protokollkette durchzulesen – angefangen bei der letzten Vollsicherung und durch alle Protokollsicherungen hindurch. Hierbei muss sich ApexSQL Log den Zwischenstatus der Datensätze merken, der über UPDATE-Befehle geändert wurde. Bei unserem Beispiel würde ApexSQL Log sowohl den Ausgangsstatus von “GRAS” als auch den Endstatus von “GLAS” erkennen und somit die gesamte Änderungshistorie wiederherstellen können.
Ein weiterer Vorteil von Protokollsicherungsdateien ist die Größe der Dateien gegenüber einer Protokolldatei, die gerade benutzt wird. Protokollsicherungsdateien sind in der Regel um ein Vielfaches kleiner und somit schneller ausgelesen.
Um diese Dateien zu analysieren, klicken Sie “Add“:
-
Nutzen Sie den Database Backups-Tab, um die Vollsicherung anzugeben, die als Anfangspunkt einer Protokollkette dienen soll:
-
Sie können dann über Time Range bei den Filtereinstellungen (Filter Setup) auch eine Zeitspanne definieren, um die Suche noch weiter einzuschränken und dabei zu beschleunigen.
- Sobald Sie bereit sind, klicken Sie Open, um das Auslesen der LDF-Dateien zu starten.
Es werden nun alle Transaktionen, die zu den angegebenen Parametern und Filtern gehören, ausgelesen und angezeigt.
Das Fazit von ApexSQL Log
Es gibt mehrere Wege, die Informationen aus einem Transaktionsprotokoll zu laden, allerdings mit viel Aufwand und fraglicher Lesbarkeit.
Mit ApexSQL Log dagegen können Sie ganz leicht die Transaktionen auslesen und die Informationen in einem brauchbaren Format anzeigen.
Ein paar Vorteile von ApexSQL Log im Vergleich zu “herkömmlichen” Lösungen:
- Automatisches Konvertieren und Darstellen von Protokolldaten aus insgesamt 129 Spalten
- Zusammenführen von mehreren LDF Dateien
- Kombinieren von Sicherungen und Online-Protokolldateien
- Rekonstruieren von UPDATE-Befehlen inkl. Vorher/Nachher-Anzeige
- Datensatzänderungshistorie inkl. Benutzernamen, Applikation und Uhrzeit
- Filtermöglichkeiten, um die Suche zu beschleunigen
- Zuweisen von alten Tabellen, die gelöscht wurden
- Keine T-SQL Kenntnisse erforderlich
ApexSQL Log geht außerdem über das reine Lesen von LDF-Dateien hinaus:
- Sortieren, Gruppieren, Filtern und Suchen von den Ergebnissen
- Ausgabe der Ergebnisse in CSV, HTML, XML oder SQL
- Automatische Skripterstellung der ausgelesenen Transaktionen. So können Sie die Änderungen rückgängig machen, ohne eine Datenbankwiederherstellung durchführen zu müssen
- Offizielle Dokumentation zu allen Features
- Technischer Support und mehr
Autor: Ivan Stankovic
Übersetzer: William Durkin
July 29, 2015