Die Zeitmaschine in der Oracle Datenbank: Praktische Anwendung von Flashback Database (Teil 1)

Seit Version 10g verfügt die Oracle Datenbank über ein eigenes Rückblendeverfahren namens Flashback Database. Mit dieser Funktionalität können Datenbankadministratoren Datenbankzustände aus der Vergangenheit rekonstruieren und unerwünschte Änderungen, wie das versehentliche Löschen von Datenbankobjekten, rückgängig machen.

Mit Flashback Database können DBAs an der Uhr drehen. Foto: Tfa1964

Wenn große Teile der Datenbank betroffen sind und eine punktuelle Wiederherstellung mit anderen Flashback Verfahren zu aufwendig oder gar unmöglich ist, können die Daten mit Flashback Database gerettet werden. Der Effekt ist vergleichbar mit einem herkömmlichen Point in Time Recovery. Flashback Database ist jedoch viel schneller, da keine Datenbankdateien aus dem letzten Backup wiederhergestellt und weniger Änderungen aus Archived Redo Logs angewendet werden müssen. Weiterhin ist die Kombination aus Flashback Database und garantierten Restore Points eine interessante Alternative zu Storage-Snapshots. Sie kann verwendet werden, um den gewünschten Zustand der Datenbank, z.B. vor einem Upgrade oder einem Testlauf, festzuhalten und bei Bedarf wiederherzustellen. Wir zeigen hier einige Anwendungsfälle von Flashback Database in der Version 11g für Single Instance Datenbanken.

So funktioniert Flashback Database

Zu diskreten Zeitpunkten speichert der Recovery Writer die veränderten Datenblöcke in spezielle Dateien, die Flashback Logs. Möchte man einen älteren Zustand der Datenbank wiederherstellen, identifiziert die Datenbank zunächst die Flashback Logs unmittelbar vor dem gewünschten Wiederherstellungszeitpunkt und der Inhalt der Flashback Logs wird in die Datafiles zurück geschrieben.

Zwischen dem Zeitpunkt der Flashback Logs und dem gewünschten Wiederherstellungszeitpunkt wurden die Daten unter Umständen weiter verändert. Diese Änderungen sind in den Redo Logs der Datenbank aufgezeichnet, so dass sie Flashback Database erneut anwenden kann. Auf diese Weise wird der exakte Zustand der Datenbank rekonstruiert.

Für das Zurücksetzten der Datenbank innerhalb eines Zeitfensters, müssen sowohl Flashback Logs als auch Redo Logs (archived und online) für diesen Zeitraum existieren. 

Drei Schritte zur Vorbereitung der Datenbank

Um die Datenbank für den Einsatz von Flashback Databse vorzubereiten, sind drei Schritte notwendig. Zunächst einmal müssen Anwender den Archivlog-Modus einstellen und die Fast Recovery Area konfigurieren, dann erst kann das Flashback Logging aktiviert werden.

Den Archivelog-Modus einstellen

Für die Nutzung von Flashback Database muss die Datenbank im Archivelog-Modus betrieben werden. Der Archivelog-Modus stellt sicher, dass eine volle Redo Log Datei archiviert wird, bevor sie erneut verwendet und damit überschrieben wird. Redo Logs sind so wichtig für Oracle Datenbanken, weil sie alle Änderungen der Datenbank dokumentieren und ihre Wiederherstellung bei Bedarf ermöglichen. Es gibt keinen treffenden Grund, weshalb Anwender sich gegen den Betrieb einer Produktionsdatenbank im Archivelog-Modus entscheiden sollten. 

Ob ihre Datenabank im Archivelog-Modus läuft, können Administratoren in SQL*Plus folgendermaßen prüfen:

Sollte der Archivlog-Modus, wie in unserem Beispiel, nicht eingeschatet sein, können die Nutzer mit folgender Befehlssequenz den Archivelog-Modus einstellen. Zu beachten ist allerdings, dass man vorher die Datenbank herunterfahren muss:

Die Fast Recovery Area konfigurieren

Flashback Database benötigt spezielle Logs, die Flashback Logs. Die Datenbank schreibt diese Logs in ein Verzeichnis auf der Festplatte namens Fast Recovery Area (FRA). Zusätzlich zu den Flashback Logs werden in der FRA auch andere Dateien gespeichert, die für die Wiederherstellung der Oracle-Datenbank notwendig sind, darunter RMAN Backups, Archived Redo Logs, Kopien von Online Redo Log files und Control Files. Es ist dem Datenbankadministrator überlassen, ob er eine FRA für seine Datenbanken konfiguriert, oder die Recovery-Dateien selber verwaltet. Für Datenbankadministratoren, die Flashback Database nutzen möchten, ist die FRA ein Muss, denn Flashback Logs können nur hier abgelegt werden.

FRA ist vorhanden, wenn die 2 Initialisierungsparameter DB_RECOVERY_FILE_DEST und DB_RECOVERY_FILE_DEST_SIZE gesetzt sind. DB_RECOVERY_FILE_DEST ist der Pfad zur FRA und DB_RECOVERY_FILE_DEST_SIZE ist die Gesamtgröße der FRA.

Falls die zwei Parameter keine Werte enthalten, können sie folgendermaßen definiert werden:

Flashback Logging aktivieren

Standardmäßig ist Flashback Database nicht aktiv. In der Version 11g kann Flashback Logging im laufenden Betrieb eingeschaltet werden. In der Version 10g musste man dafür die Datenbank in den Mount-Modus versetzen.

Ab diesem Zeitpunkt generiert die Datenbank Flashback Logs in der FRA.

Flashback Database im Einsatz

Nun ist Flashback startklar. Wie man mit Flashback Database eine unerwünschte Aktion rückgängig macht, weiß der DBA unserer fiktiven Firma: Der User HR wollte die Tabelle JOB_HISTORY in der Testdatenbank aufräumen. Dabei wusste er nicht, dass er mit der Produktionsdatenbank verbunden war, als er folgenden Befehl ausführte:

Nun war die Tabelle JOB_HISTORY leer. Als andere Benutzer dies merkten, riefen sie den DBA an. Welche Möglichkeiten stehen dem DBA zur Verfügung um die Tabelle wiederherzustellen? Der einfachste Weg ist flashback table. Aber für flashback table muss Undo vorhanden sein und truncate table (als DDL-Operation) hat kein Undo erzeugt.

Statt zum letzten Backup zu greifen, behalf sich der DBA mit flashback database, um die gesamte Datenbank auf den Zustand vor Eintritt des Fehlers  zurückrollen. Die Produktionsdatenbank hatte er schon vor einiger Zeit für Flashback Database vorbereitet. So musste er nur noch den richtigen Zeitpunkt (oder die System Change Number, SCN) ausfindig machen und feststellen, wann der Fehler eingetreten war. Dank der Hilfe der HR-Abteilung, die ihm den ungefähren Zeitpunkt mitteilte, konnte er die Wiederherstellung in Gang setzen. Vor zirka 10 Minuten sei der truncate ausgeführt worden, hieß es.

So sah der Wiederherstellungsprozess in SQL*Plus aus: Der DBA stoppte die Datenbank, öffnete sie im Mount-Modus und setzte den flashback database Befehl ab.

Dann öffnete unser DBA die Datenbank. Dabei kann diese read only oder mit dem Zusatz resetlogs geöffnet werden. read only ist eine gute Option, wenn sich der DBA vergewissern möchte, dass die Datenbank auf den richtigen Zeitpunkt zurückgerollt wurde:

Vor 10 Minuten war der Inhalt der Tabelle bereits gelöscht worden! Nun musste er sich durch weitere flashback database Befehle an den richtigen Zeitpunkt herantasten. Vor 15 Minuten  waren die Daten in der Tabelle vorhanden. Ist man zu weit zurück gegangen, kann man aber problemlos einen späteren Zeitpunkt rekonstruieren, hier vor 14 Minuten (entspricht 13:52 Uhr).

Nachdem er den gewünschten Zustand identifiziert hatte, öffnete er die Datenbank mittels resetlogs.

Mit Flashback Database konnte der DBA flexibel durch die Historie der Datenbank vor- und rückwärts navigieren. Die Voraussetzung dafür: Es waren genügend Flashback Logs vorhanden.

Neben Änderungen an Daten und Datenbankobjekten können auch Datenbanknutzer und ihre Daten wiederhergestellt werden. Dafür müssen die Datafiles mit den Nutzerdaten existieren, denn Flashback Database ist (leider) kein Kompensationsmittel für den Verlust oder die Beschädigung von Datenbankdateien.

• Teil 2: Flashback Database - Die Zeitmaschine ohne Datenverlust nutzen