6 Minuten Lesezeit (1148 Worte)

Flashback – Reise in die Vergangenheit: Warum Oracle Zeitreisen anbieten kann, der Microsoft SQL Server aber nicht

Dienstag, 25. April 2017

Warum bietet Oracle die Funktionalität „Flashback-Query" und der MS SQL Server nicht? Wie sich die beiden Datenbankmanagementsysteme in ihrer Arbeitsweise und Funktionalität unterscheiden, werden wir näher erläutern. Dabei werden auch die Begriffe Lesekonsistenz und Isolationslevel behandelt.

Wie sahen die Daten gestern aus?

Der Blick zurück wird bei Oracle durch die Erweiterung der Abfrage um den „AS OF"-Zusatz realisiert:

SELECT * FROM mitarbeiter AS OF TIMESTAMP SYSDATE - 1

Mit dieser Abfrage wird der Stand der Tabelle wiedergegeben, wie er 24 Stunden vor Beginn der Abfrage gültig war. Bereits an dieser Stelle sei erwähnt: Das klappt natürlich nicht in jedem Fall. Es müssen bestimmte Voraussetzungen erfüllt sein, die im Folgenden näher betrachtet werden.

Ablauf einer Transaktion

Bei einer Transaktion gilt das „Alles oder Nichts"-Prinzip. Es bedeutet, dass alle im Rahmen einer Transaktion durchgeführten Änderungen entweder vollständig umgesetzt oder komplett rückgängig gemacht werden. Die beiden wichtigsten Aspekte beim Ablauf einer Transaktion sind: Den Weg zurück sichern und die Änderung garantieren.

Um den Weg zurück zu sichern, wird zu jeder Datenänderung die entgegengesetzte Datenänderung generiert und gesichert. Bei Oracle spricht man vielfach vom „Before Image", generell von Undo-Informationen. Um die Änderungen nach der Bestätigung des Commit zu garantieren, wird vor dem Versenden dieser Bestätigung sichergestellt, dass alle Datenänderungen selbst gesichert wurden. Bei Oracle spricht man auch vom „After Image", generell von Redo-Informationen.

Von der Verarbeitung dieser Informationen völlig unabhängig erfolgt die Übertragung der geänderten Daten aus dem Buffer Pool in die Datendatei zu einem anderen (meist später liegenden) Zeitpunkt. Diese Verarbeitung ist für die folgenden Überlegungen nicht relevant und wird daher nicht weiter betrachtet.

Technische Umsetzung

Beim MS SQL Server werden die Informationen zunächst im Hauptspeicher, genauer gesagt im Log Buffer gehalten. Dieser relativ kleine Bereich, mit wenigen MB, enthält die Redo- und die Undo-Informationen in Form von Statements. Er wird in kurzen Intervallen und auf jeden Fall beim Commit auf die Festplatte geschrieben. Dort landen die Informationen im Transaktionsprotokoll, einer Datei, die mitunter relativ groß werden kann. Denn je nach Konfiguration der Datenbank werden die einzelnen Bereiche dieser Datei (Virtual Log Files) erst dann zur Wiederverwendung freigegeben, wenn die Informationen durch ein Backup (genauer gesagt durch eine Transaktionsprotokollsicherung) verarbeitet wurden.

Auch Oracle besitzt einen Log Buffer mit der gleichen Funktionalität wie der MS SQL Server. Allerdings werden die Undo- und Redo-Informationen im Folgenden nicht gemeinsam verarbeitet. So besitzt Oracle eine zusätzliche Komponente: Den Undo Tablespace. Dieser enthält die Daten-Werte aus den Undo-Informationen, also die „Before Images". Da es sich um einen Tablespace handelt, liegen die Informationen sowohl im Hauptspeicher als auch auf der Festplatte vor, alle Änderungen werden ebenfalls durch Redo-Informationen gesichert. Damit liegen diese Informationen auch nach dem Ende der Transaktion und sogar nach einem Neustart der Instanz weiterhin vor.

Die Redo-Informationen werden bei Oracle, ähnlich wie beim MS SQL Server, in Redo Log Files geschrieben. Oracle verwendet dabei mindestens zwei Dateien mit einer festen Größe von mindestens 4 MB. Ist die aktive Datei voll, wird diese geschlossen und die andere Datei zur aktiven Datei. Die geschlossenen Dateien werden vom Archiver in die Archive Destination kopiert und stehen dort für die Wiederherstellung der Datenbank zur Verfügung.

Wichtigster Unterschied zwischen den beiden Systemen und der Schlüssel zu Flashback-Query sind die längerfristig zugänglichen Undo-Informationen bei Oracle.

Lesekonsistenz

Diese Undo-Informationen werden bei Oracle dazu genutzt, lesenden Abfragen einen konsistenten Stand der Informationen zum Zeitpunkt des Beginns der Abfrage zur Verfügung zu stellen. Dabei werden diese nicht von ändernden Zugriffen blockiert, da ältere Stände aus den Undo-Informationen rekonstruiert werden (Abbildung 1) ‒ jedenfalls so lange, wie der Undo Tablespace groß genug ist, um alle benötigten Informationen aufzunehmen.

Beim MS SQL Server richtet sich das Verhalten nach dem verwendeten Isolationslevel. Beim Standard „Read Committed" erzeugen ändernde Abfragen Sperren auf den betroffenen Datensätzen. Die lesenden Zugriffe werden dadurch blockiert und müssen auf das Ende der schreibenden Transaktion warten.

Die alternativen Isolationslevel „Snapshot" und „Read Committed Snapshot" verändern das Verhalten und ermöglichen, wie bei Oracle, einen lesekonsistenten gleichzeitigen Zugriff. Erreicht wird dies durch den Aufbau von Zeilen-Versionen in der tempdb. Die Aktivierung dieser Isolationslevel ändert jedoch den Aufbau der Daten in den Dateien, da in jeden Datensatz ein zusätzlicher 14 Bytes großer Zeiger zu den Zeilen-Versionen eingefügt wird.

Ein entscheidender Unterschied zu Oracle bleibt: Die Zeilen-Versionen sind nur bis zum Neustart der Instanz verfügbar. Ein Bereinigungsprozess entfernt bereits im Vorfeld die nicht mehr benötigten Zeilen-Versionen von laufenden Transaktionen.

Flashback-Query

Warum ist die Dauer der Speicherung von Undo-Informationen so wichtig? Weil Flashback-Query nichts anderes ist als eine konsequente Erweiterung der Lesekonsistenz in die Vergangenheit.

Mithilfe der Undo-Informationen kann der Zustand der Daten nicht nur zum Zeitpunkt des Beginns der Abfrage, sondern auch zu anderen Zeitpunkten in der Vergangenheit bereitgestellt werden. Voraussetzung ist natürlich, dass diese Informationen noch im Undo Tablespace vorliegen.

Konfigurationsparameter

Zwei Konfigurationsparameter haben direkten Einfluss auf die Verfügbarkeit von Flashback-Query. Zum einen die Option UNDO_RETENTIONfür das System. Diese Angabe in Sekunden bestimmt, wie lange die Undo-Daten nach Ende einer Transaktion vorgehalten werden. Dieser Wert gilt nur für automatisch vergrößernde Undo Tablespaces. Des Weiteren darf die MAXSIZE nicht erreicht werden.

Zum anderen kann die Option RETENTION GUARANTEE für den Undo Tablespace die unbedingte Einhaltung der UNDO_RETENTION garantieren. Dies kann jedoch zu Abbrüchen von schreibenden Transaktionen führen, wenn nicht ausreichend Speicher vorhanden ist.

Fazit

Die getrennte und persistente Speicherung der Undo-Daten ist der Schlüssel zur Zeitreise. Anhand dieses Features zeigt sich auch, welche Auswirkung die unterschiedliche Architektur der Datenbankmanagementsysteme auf die Verarbeitung von Abfragen hat.

Noch ein abschließender Hinweis: In Produktionsumgebungen wird Flashback-Query sicherlich sehr selten eingesetzt. Für Entwicklungen und Tests kann das Feature jedoch durchaus sinnvoll eingesetzt werden.

Glossar

Isolation
Die Trennung von Transaktionen auf eine Weise, dass eine laufende Transaktion nicht von einer parallel ablaufenden Transaktion durch Änderung der benutzten Daten in einen undefinierten Zustand gebracht werden kann.

Isolations-Level
Der Isolation-Level bestimmt, wann das Datenbanksystem welche Sperren setzt. Damit wird festgelegt, welche Abfragen parallel aufgeführt werden können und welche Abfragen auf das Ende von anderen Abfragen warten müssen.

Redo Log-Dateien
Redo Log-Dateien speichern Informationen über alle Datenänderungen in den Tablespace-Dateien. Sie können im Falle eines Speichermedium-Fehlers zur Rekonstruktion der Daten herangezogen werden. Es müssen mindestens zwei Redo Log-Dateien (mindestens zwei Gruppen mit jeweils mindestens einer Datei) für jede Database definiert sein.