Seit Version 9i gibt es den Begriff „Flashback“ in der Oracle-Technologie. Trotzdem ist es oft schwierig, die unterschiedlichen Begriffe und zugehörigen Technologien zu harmonisieren.
Fangen wir mit den Definitionen an: Flashback bedeutet, zumindest in der Oracle-Terminologie, dass ein früherer Zustand wiederhergestellt werden soll. Könnte sein, dass man den Zustand eines Datensatzes vor einer Stunde sehen will, die Tabelle, bevor sie gelöscht wurde, oder die Änderung von letztem Monat. Und hier sind wir bei der eigentlichen Frage: Was muss ich tun um solche Voraussetzungen zu erfüllen?
Beginnen wir mit dem Feature, dass einem wahrscheinlich als erstes einfällt: Flashback Database.
Wofür brauchen wir das?
Mit Flashback Database ist es möglich, die gesamte Datenbank zurückzurollen, das bedeutet das gesamte Datenset auf einen früheren Zeitpunkt zurückzusetzen.
Was brauchen wir dafür?
Flashback Database ist nur in der Enterprise Edition verfügbar. Obwohl einige etwas anderes behaupten: Zuerst muss man überhaupt nichts machen, außer dass die Datenbank im Archivelog-Modus sein muss. Damit kann dann jederzeit ohne erneutes Stoppen und Starten der Datenbank ein Guaranteed Restore Point erstellt und die Datenbank nach Änderungen auf diesen Punkt zurückgesetzt werden.
SQL> CREATE RESTORE POINT before_batch GUARANTEE;
Das ist beispielsweise hilfreich, wenn ein Fallback durch einen Batch-Run verfügbar sein soll oder beim Einspielen eines neuen Anwendungs-Releases. Das bedeutet, der Restore Point wird vor dem Batch-Run gesetzt und, wenn man nach dem Run irgendwelche Fehler feststellt, wird die Datenbank einfach darauf zurückgesetzt. Wenn das Batch ordentlich durchgeführt wurde, wird der Restore-Point gelöscht – und das sollten Sie auf keinen Fall vegessen, weil dann die Fast Recovery Area in kurzer Zeit voll wäre und die Datenbank anhalten würde.
Warum das?
Bei Flashback Database werden Flashback-Logs geschrieben. Das bedeutet, wenn sich ein Datenbankblock das erste Mal ändert, wird eine Kopie davon in die Fast Recovery Area geschrieben. Wird die Datenbank zurückgesetzt, werden diese Blöcke einfach ausgetauscht und, wo möglich, ein Recovery mit den Informationen aus der archivierten Redo-Log-Datei gefahren. Das ist notwendig, da man den Guaranteed-Restore-Point im laufenden Betrieb setzen kann.
Dies ist eine eingeschränkte Funktion, da man vorher wissen muss, dass man möglicherweise zurückrollen möchte. Wenn man seine Datenbank zu jeder Zeit auf einen früheren Zeitpunkt zurücksetzen möchte, muss man Flashback-Database dauerhaft aktivieren. Wie auch ein Guaranteed Restore Point kann auch das generelle Flashback Database jederzeit eingeschaltet werden, wenn die Datenbank im Archive-Log Modus betrieben wird.
SQL> ALTER DATABASE FLASHBACK;
Anschließend kann der aktuelle Zustand durch den View v$database abgefragt werden:
SQL> SELECT flashback_on, log_mode FROM v$database; FLASHBACK_ON LOG_MODE ------------------ ------------ YES ARCHIVELOG
Jetzt kann die Datenbank zu jeder Zeit auf jeden Zeitpunkt zurückgesetzt werden. Wirklich jeden Zeitpunkt?
Durch den Parameter db_flashback_retention_target kann man in Minuten (!) bestimmen, wie weit man in die Vergangenheit zurückrollen möchte. Realistisch sind hier zwischen ein und drei Tagen, je nachdem wie viel Speicher man der Fast Recovery Area zuteilt.
Die Datenbank kann so weit in die Vergangenheit zurückgesetzt werden, wie der älteste Falshback-Log reicht. Jeder neuere Punkt kann über einen neueren Log und zwischenzeitlich angefallene, archivierte Redo-Log-Daten erreicht werden.
Flashback-Logs oder Storage-Snapshots?
Viele Speicher-Hersteller bieten heutzutage Snapshot-Funktionen an. Das bedeutet, die geänderten Blöcke (egal ob Datenbank oder andere Dateien) werden vorübergehend in einer Snapshot-Area gespeichert. Dadurch ist es auch möglich die Datenbank auf einen früheren Zustand zurückzurollen. Im Gegensatz zu Flashback-Database ist es oft nicht möglich die Datenbank auf einen früheren Zeitpunkt zurückzurollen, read-only zu öffnen und anschließend vorzurollen zum vorigen Zustand. Dies ist interessant, wenn man beispielsweise Dataguard benutzt, da man die Standby-Datenbank zurückrollen, eine Tabelle ansehen oder kopieren und dann wieder vorrollen kann. Die Verfügbarkeit bleibt während dieser Zeit bestehen. Beachten Sie in Verbindung mit Dataguard, dass auch ein „Wiedereinsetzen (reinstate)“ der Primär-Datenbank nach einem Fehler nur möglich ist, wenn Flashback-Database aktiviert ist.
Und noch ein Tipp: Vorsicht mit Dataguard! Wenn man mit RMAN kopiert (doppelt für Standby), werden die Flashback-Database-Einstellungen nicht übertragen, was bedeutet, man muss sie auf der Standby-Seite nochmal aktivieren.
Fazit
Obwohl die Flashback-Logs Disk-Speicher brauchen, zahlt sich die Aktivierung in jedem Fall aus. Und wenn man das nicht will, kann man mit den Guaranteed-Restore-Points wenigstens haufenweise Exporte sparen.
In meinem nächsten Blog werde ich auf das Thema Flashback-Table eingehen, für das drei (!) unterschiedliche Vorgehensweisen verwendet werden.