Über unsMediaKontaktImpressum
Andrea Held 03. November 2015

Oracle Flashback - Zurück in die Zukunft!

Es passiert nicht oft. Aber es passiert. Kurz nachdem der Finger auf die Tastatur niedersauste, um Enter zu drücken, durchfährt es den Admin: "Oooops, das war falsch!"

Menschliche Fehler sind eine der häufigsten Ursachen für Systemausfälle. Einer Studie von Gartner zufolge fallen 32 Prozent der Downtimes in diese Fehlerkategorie. Oracle will hier Abhilfe schaffen und hat bereits in der Version 10.x eine Restore-Möglichkeit geschaffen, die kein anderes DBMS derzeit in diesem Umfang beherrscht. Flashback heißt die Technologie, die Administratoren das Leben erleichtern soll. Die Wiederherstellungszeit im Fall von Benutzerfehlern und bei logischen Fehlern der Anwendung kann durch Einsatz von Flashback oft auf wenige Minuten reduziert werden.

Hat ein Benutzer versehentlich Daten gelöscht oder in unbeabsichtigter Weise verändert, so gab es – mit Ausnahme von Standby-Konfigurationen mit Delay – bis einschließlich Oracle 9.x nur eine Möglichkeit: Die Datenbank musste in solchen Fällen mit einem Backup wiederhergestellt werden, anschließend war ein Point-in-Time Recovery bis zu dem Zeitpunkt unmittelbar vor dem Benutzerfehler erforderlich. Bei einer großen Datenbank kann dieses Vorgehen zeitaufwändig sein. Zudem sind alle Datenänderungen, die Transaktionen nach dem Benutzerfehler betreffen, verloren.

Oracle Flashback bietet für diese Problemstellung einen vereinfachten Workaround an. Mit wenigen Befehlen lassen sich Änderungen zurücksetzen oder gelöschte Daten wiederherstellen. Dabei können im Hinblick auf Funktionalität, Architektur und Implementierung recht unterschiedliche Flashback-Typen zum Einsatz kommen, beispielsweise

  • Flashback Query: Abfrage der Änderungshistorie
  • Flashback Table: Zurücksetzen von Änderungen
  • Flashback Drop: Wiederherstellen gelöschter Tabellen
  • Flashback Database: Zurücksetzen der kompletten Datenbank

Flashback Query und Flashback Table: Übersicht

Flashback Query nutzt die Before Images des Undo Tablespaces, um den Zustand von Datensätzen in einer Historie abzufragen. Flashback Table wiederum greift auf dieselbe Technologie zurück, um den Datenbestand einer einzelnen Tabelle auf einen historischen Zeitpunkt zurückzusetzen.

Dabei werden die Before Images, die Oracle für ein eventuelles Rollback von Transaktionen anlegt, über den Commit-Zeitpunkt hinaus aufbewahrt und bei Anwendung der genannten Flashback-Typen ausgelesen.

Flashback Query ist allerdings nicht für die dauerhafte Historisierung geeignet: Der Zeitraum, für den rückwirkend abgefragt werden kann, ist durch die Größe des Undo Tablespaces und das Transaktionsvolumen der Datenbank limitiert. Meist sind diese Abfragen auf historische Daten auf wenige Stunden bis maximal einige Tage beschränkt. Für ein Flashback im Fehlerfall ist dieser Zeitraum jedoch im Regelfall ausreichend.

Flashback Drop: Übersicht

Flashback Drop nutzt den Recycle Bin, eine Art Papierkorb, um gelöschte Tabellen in Sekundenschnelle wiederherzustellen. Wird eine Tabelle eines normalen Benutzers gelöscht, so wird sie – sofern nicht explizit etwas anderes angegeben wurde – zunächst nicht physisch aus der Datenbank entfernt, sondern einfach in den Recycle Bin verschoben. Von dort kann sie in Sekundenschnelle wiederhergestellt werden. Im Hintergrund wird als nur das Data Dictonary der Oracle Datenbank geändert. Die Tabellendaten bleiben vorläufig bestehen.

Dies gilt nicht für die Benutzer sys und system. Objekte dieser Administrationsbenutzer werden mit dem drop Befehl nachhaltig aus der Datenbank entfernt.

Beim Löschen der Tabellen mit drop table werden auch alle abhängigen Objekte entfernt. Beim Wiederherstellen werden diese daher auch gemeinsam wiederhergestellt. Das gilt für Objekte wie Indizes und Trigger. Eine Ausnahme bilden referentielle Constraints (Foreign Key Constraints): Sie werden bei einem Flashback Drop nicht wiederhergestellt.

Flashback Database: Übersicht

Flashback Database schließlich verwendet die mit Oracle 10g eingeführten Flashback Logs. Sie sie aktiviert, so wird in diesen eine datenbankweite Historie der Block Images in einem speziellen Bereich des Filesystems, dem Recovery File Destination mitgeschrieben: Hier werden Datenbank-Blöcke abgelegt.

Im Bedarfsfall kann mittels Flashback Logs in Kombination mit archivierten Redologs die gesamte Datenbank in kurzer Zeit zu einem historischen Zustand zurückgerollt werden. Der dafür notwendige Zeitaufwand variiert in Abhängigkeit vom Transaktionsvolumen der Datenbank sowie dem Zeitraum, um den zurückgesetzt werden soll. In der Regel wird hierfür nicht viel mehr als einige Minuten benötigt.

Tabelle 2: Übersicht der Flashback-Architekturen

Typ Ursache Funktionalität
Flashback Query Undo Management Abfrage der Datensatz-Historie / Row History
Flashback Table Undo Management Zurücksetzen einer Tabelle auf einen historischen Zeitpunkt
Flashback Drop Verwendung eines internen Recycle Bin Wiederherstellen einer gelöschten Tabelle
Flashback Database Flashback Logs und Archive Logs Zurücksetzen der gesamten Datenbank auf einen historischen Zeitpunkt

Welche der Flashback Optionen Anwendung finden sollte, hängt von der konkreten Anforderung ab. Soll nur die Datensatzhistorie überprüft werden, so kann diese mit Flashback Query erfragt werden. Einzelne Tabellen werden mit Flashback Table zurückgesetzt. Flashback Drop stellt versehentlich gelöschte Tabellen wieder her. Flashback Database schließlich rollt den Datenbestand der gesamten Datenbank auf den Stand des angegebenen Zeitpunktes zurück.

Tabelle 3: Hochverfügbarkeit durch Einsatz von Flashback

Ausfalltyp Ursache Workaround
Ungeplant Komplexe Anwender- und Administrationsfehler sowie komplexe logische Fehler einer Applikation Datenbankweites Zurücksetzen aller Transaktionen mit Flashback Database
Ungeplant Administrationsfehler: versehentlich gelöschte Tabelle Wiederherstellen der Tabelle aus dem Recycle Bin mit Flashback Drop
Ungeplant Anwenderfehler sowie logische Fehler der Applikation auf Tabellenebene Zurücksetzen der Transaktionen einer Tabelle mit Flashback Table
Geplant Datensatzhistorie innerhalb der Undo Retention Time Abfrage der Before Images aus dem Undo Tablespace mit Flashback Query

Eine Datenbank für den Einsatz von Oracle Flashback konfigurieren

Je nach Architektur des Flashback-Typs sind unterschiedliche Voraussetzungen zu erfüllen. Diese werden im Folgenden erläutert.

Flashback Table und Flashback Query: Voraussetzungen konfigurieren

Um Flashback Table und Flashback Query einsetzen zu können, wird der Undo Tablespace benötigt. Da Flashback Table und Flashback Query die Before Images des Undo Bereiches lesen, ist es notwendig, diese Before Images für eine ausreichende Dauer aufzubewahren. Für welchen Zeitraum dies möglich sein sollte, ist anwendungsabhängig und muss in Anlehnung an die Kundenanforderungen in jedem Einzelfall bestimmt werden. Nach diesen Vorgaben wird über den Datenbank Parameter undo_retention die Aufbewahrungsdauer der Undo Before Images gesetzt. Der Default Wert der Undo Retention Periode beträgt 900 Sekunden.

Um alle Before Images von Transaktionen der Retention Periode aufnehmen zu können, sollte der Undo Tablespaceausreichend groß dimensioniert werden. Welche Datenmenge hier abgedeckt werden muss, hängt vom Transaktionsaufkommen ab. Hier sollten Sie mittels Transaktionsaufkommen berechnen, welche Größe mindestens für einen gegebenen Aufbewahrungszeitraum erforderlich ist. Auch der Oracle Undo Advisor kann hilfreich sein. 

Wie funktioniert Flashback Query im Detail? Der Undo Tablespace ist einigen sicherlich aus einem anderen Kontext bekannt: Er stellt den Speicherplatz bereit, in dem vor der Änderung eines Datensatzes eine Sicherungskopie (das Before-Image) abgelegt wird. Diese wird normalerweise genutzt, um im Fall des Befehls Rollback die Änderungen wieder rückgängig machen zu können. Bislang wurden diese Before-Images aber nach einer Bestätigung der Änderungen durch einen Commit-Befehl zum Überschreiben freigegeben. Damit waren diese Sicherungskopien verloren.

Ab Oracle 10g nutzt die Datenbank den Undo-Speicherbereich zusätzlich, um Änderungen auch nach einem Commit noch einsehen und – falls gewünscht – auch wieder rückgängig machen zu können. Allerdings ist dies nur für einen begrenzten Zeitraum möglich: Ist der Undo Tablespace irgendwann einmal voll, so werden die ältesten Before Images wieder beschrieben. Nach einiger Zeit sind also jeweils jene Daten, deren Änderungen am längsten her sind, verloren. Die Größe des Zeitraumes, für den die Änderungshistorie zur Verfügung steht, hängt von der Größe des Undo Bereiches ab. Dieser kann frei konfiguriert werden.

Der Undo Tablespace ist also eine Art Ringspeicher für Before Images bei Datenänderungen:

  • Solange noch freier Speicherplatz vorhanden ist, wird dieser beschrieben.
  • Ist der Undo-Bereich gefüllt, wird mit dem Beschreiben wieder "von vorn" begonnen. Dabei werden die ältesten Bereiche überschrieben.

Tabelle 4 zeigt die für die Konfiguration des Undo Tablespaces erforderlichen Paramenter. Die Verweilzeit von Before Images wird mit dem Parameter undo_retention gesteuert. Aber Achtung: Dies dient nur als Hinweis, diese Aufbewahrungsdauer wird nicht garantiert. Möchte man eine Garantie erzwingen, so muss dies für den Undo Tablespace konfiguriert werden. Das wird mit dem Befehl alter tablespace mittels der Klausel retention guarantee erreicht.

ALTER TABLESPACE undotbs1 RETENTION GUARANTEE;

Änderungen im Server Parameter File (SPFile) werden mit dem Befehl alter system konfiguriert:

ALTER SYSTEM 
SET UNDO_MANAGEMENT = AUTO
SCOPE=SPFILE;
ALTER SYSTEM 
SET UNDO_TABLESPACE = 'undotbs'
SCOPE=SPFILE;
ALTER SYSTEM 
SET UNDO_RETENTION = 18000
SCOPE=SPFILE;

Möchte man nur zur Laufzeit ändern, ohne dass die Änderung nach einem Datenbank-Restart erneut zieht, so kann man dies mit der Klausel scope=memory bewirken. Ebenso kann man mit der Klausel scope=spfile nur in das SPFile schreiben, ohne eine Laufzeitänderung zu verursachen. In diesem Fall zieht der Parameter erst nach einem Restart.

ALTER SYSTEM 
SET UNDO_RETENTION = 18000
SCOPE=MEMORY;
ALTER SYSTEM 
SET UNDO_RETENTION = 18000
SCOPE=SPFILE;
ALTER SYSTEM 
SET UNDO_RETENTION = 18000
SCOPE=BOTH;

Wird die Scope-Klausel nicht gesetzt, so wird der Default both eingesetzt: Die Änderung greift zur Laufzeit und wird zudem über das SPFile persistent gemacht.

Tabelle 4: Datenbank-Parameter im Umfeld des Undo Managements

Parameter Wert
UNDO_MANAGEMENT Auf AUTO setzen
UNDO_TABLESPACE Name des Undo Tablespaces, der verwendet werden soll
UNDO_RETENTION Anzahl Sekunden, für die der Undo Tablespace die Before Images aufbewahren soll

Möchte man die Größe des Undo Tablespaces selbst errechnen, so ist folgendermaßen vorzugehen:

[UndoBlockCount] = UR * UPS + OV

Wobei

  • UndoBlockCount die Anzahl der Undo Blöcke,
  • UR die undo_retention in Sekunden,
  • UPS die Anzahl der Undo Blöcke pro Sekunde und
  • OV den Overhead für Metadaten (Transaktionstabellen und Bitmaps)

bezeichnet.

Da Berechnungen basierend auf der Transaktionsaktivität einer gewissen Unschärfe unterliegen, kann der Overhead vernachlässigt werden.

Bei einer angenommenen Undo Retention-Periode von 2 Stunden und einer Transaktionsrate (UPS) von 200 Blöcken je Sekunde ergibt sich bei einer Block Size von 4 K:

[UndoBlockCount] =(2 * 3600 * 200 * 4K) ? 5.49GB.

Als Basis dieser Berechnungen dienen Informationen der Tabelle v$undostats. Ihr kann die Anzahl geänderter Undo-Blöcke innerhalb eines Zeitraumes entnommen werden.

SQL> select min(begin_time), max(end_time), sum(undoblks) 
 2   from v$undostat;
MIN(BEGIN_TIME)     MAX(END_TIME)       SUM(UNDOBLKS)
------------------- ------------------- -------------
20.06.2015 15:45:36 20.06.2015 17:58:34        231126

Im obigen Beispiel wurde in einem Zeitraum von 2 Stunden 12 Minuten und 58 Sekunden, insgesamt also 7.978 Sekunden eine Anzahl von 231.126 Undo Blöcke beschrieben. Hieraus ergibt sich eine Transaktionsrate von rund 29 Undo Blöcken pro Sekunde.

Bei einer Retention Time von 2 Stunden und einer Blockgröße von 4 K ergibt sich:

[UndoBlockCount] =(2 * 3600 * 29 * 4K) ? 812,6 MB

Damit ein Benutzer eine Table zurücksetzen kann, benötigt er die Privilegien flashback table, insert, update und delete für die betreffende Tabelle oder aber das DBA-Privileg flashback any table. Letzteres gestattet, jede beliebige Tabelle mit einem Flashback Table-Befehl zurückzusetzen.

Zusätzlich müssen Sie für die betreffende Tabelle Row Movement aktivieren. Die Syntax lautet:

alter table <table_name> enable row movement;

Flashback Drop: Voraussetzungen konfigurieren

Der Recycle Bin ist ein logischer Container, in dem gelöschte Tabellen und deren abhängige Objekte (Indizes, Constraints mit Ausnahme von Foreign Keys, LOB-Segmente etc.) aufbewahrt werden.

Im Hintergrund wird beim Löschen einer Tabelle das betreffende Objekt im Data Dictionary der Datenbank umbenannt. Es wird also nicht physisch gelöscht, sondern sozusagen in den Papierkorb verschoben. Bei einem Flashback Drop wird dieser Vorgang des Umbenennens einfach in umgekehrter Richtung vorgenommen: Das Objekt erhält wieder seinen alten Namen und Owner.

Objekte im Recycle Bin werden nicht als genutzer Speicher gerchent. Abfragen auf Free Space zeigen diese Objekte also nicht. Data Dictionary-Views wie user_tables, all_tables und dba_tables, user_indexes, all_indexes und dba_indexes zeigen die Objekte weiterhin. Die Spalte "dropped" zeigt für sie den Wert "YES". Um nur Objekte des Recycle Bin abzufragen, können Sie die Views user_recyclebin und dba_recyclebin abfragen.

Damit der Recycle Bin genutzt wird, muss er aktiviert sein. Auf Session-Ebene kann dies wie folgt eingestellt werden:

ALTER SESSION SET RECYCLEBIN=ON; 

bzw.

ALTER SESSION SET RECYCLEBIN=OFF; 

Um die Einstellung für die komplette Datenbankinstanz zu ändern, wird der Befehl alter system verwendet:

ALTER SYSTEM SET RECYCLEBIN=ON;

bzw.

ALTER SYSTEM SET RECYCLEBIN=OFF; 

Objekte, die bereits im Recycle Bin abgelegt sind, sind von einer Änderung der Einstellungen nicht betroffen. 

Flashback Database: Voraussetzungen konfigurieren

Das Ergebnis eines Flashback Database entspricht im Grunde einem Point in Time Recovery. Die Datenbank wird in einen konsistenten Zustand eines Zeitpunktes in der Vergangenheit zurückgesetzt. Jedoch ist der notwendige Zeitraum zur Wiederherstellung des gewünschten Zeitpunktes mit Flashback Database wesentlich kürzer als jener, der für eine Point in Time Recovery erforderlich ist.

Damit ein Flashback der gesamten Datenbank überhaupt möglich ist, sind einige Voreinstellungen notwendig. So muss die Datenbank im Archivelog Mode betrieben werden. In diesem Modus werden Transaktionslogs der Datenbank, die Online Redo Logs, in ein Archivierungsziel gesichert, bevor sie neu überschrieben werden. Diese archivierten Transaktionslogs werden im Fall eines Flashback Database benötigt. Zusätzlich werden Flashback Logs benötigt. Diese werden im Flash Recovery Area hinterlegt.

Die Flash Recovery Area (FRA) ist ein mit Oracle 10g eingeführter Speicherbereich für alle Dateien einer Oracle Datenbank, die mit Recovery in Beziehung stehen. RMAN-Sicherungen, Archived Redo Logs, Control File Autobackups und Datenfile-Kopien werden automatisch in diesen im Datenbank Parameter db_recovery_file_dest spezifizierten Pfad abgelegt. Es kann sich hierbei um ein Verzeichnis in einem Standard-Filesystem, aber auch um eine ASM Disk Group handeln.

SQL> alter system set db_recovery_file_dest_size = 100G;
System altered
SQL> alter system set db_recovery_file_dest = /oradb/backup;
System altered

Voraussetzung für die Möglichkeit eines Flashback Database ist, dass die Datenbank im Archive Log Mode und zusätzlich im Flashback Mode betrieben wird. Dies kann beispielsweise wie folgt aktiviert werden:

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
SQL> alter database archivelog;
Database altered.
SQL> alter database flashback on;
Database altered.
SQL> alter database open;
Database altered.
SQL> alter system set log_archive_start = TRUE;
Database altered.

Abschließend sollte geprüft werden, ob der Flashback- und der Archive Log Mode aktiviert sind. Dies kann über die Abfrage der View v$database ermittelt werden. Die Spalten [flashback_on] und [log_mode] geben hierüber Auskunft:

SQL> SELECT flashback_on, log_mode FROM v$database;
FLASHBACK_ON  LOG_MODE
------------  ----------
YES           ARCHIVELOG

Für Flashback Database gibt es ein gesondertes Retention Target. Dieses bezieht sich nicht auf die Undo-Informationen, sondern auf die Flashback Logs im Betriebssystem. Die Größe dieser Logs hängt von der Größe des in db_flashback_retention_target angegebenen Zeitraumes ab. Über den Befehl show parameter kann dieser Wert ermittelt werden:

SQL> show parameter db_flashback_retention_target
NAME                                 TYPE        VALUE
------------------------------------ ----------- ---------------
db_flashback_retention_target        integer     1440

Der Default für Flashback Retention Target von 1.440 Minuten kann über den Befehl alter system angepasst werden.

Die Frage, wie weit mit existierenden Flashback Logs zurückgesetzt werden kann und wie viel Speicherplatz für das Flashback benötigt wird, kann mit Hilfe der View v$flashback_database_log oder aber mit dem Enterprise Manager beantwortet werden:

SQL> SELECT oldest_flashback_scn, oldest_flashback_time 
2>   FROM   v$flashback_database_log;
OLDEST_FLASHBACK_SCN OLDEST_FLASHBACK ESTIMATED_FLASHBACK_SIZE
-------------------- ---------------- ------------------------
11355608             21.06.2004 08:23                449691648

Der Wert der Spalte [estimated_flashback_size] gibt die Größe des geschätzten notwendigen Flashback Datenvolumens in Bytes an.

Anwendung der Flashback-Technologien

Im Folgenden wird gezeigt, wie Sie Oracle Flashback anwenden können.

Flashback Query anwenden: Abfrage historischer Daten 

Flashback Query lässt sich mit einigen ganz einfachen Mitteln einsetzen. Dabei wird in einer Abfrage einfach nur angegeben, auf welchen Zeitpunkt man zurückgreifen möchte. Ein Beispiel: Es ist Montag, der 02.03.2004 kurz vor der Mittagspause. Herr Müller aus der Personabteilung ruft an. Er berichtet, er habe ganz sicher gar nichts gemacht. Dennoch sei – wie er feststellen musste – die Abteilung mit der Abteilungsnummer 50 plötzlich und gänzlich ohne sein Zutun aus dem Datenbestand einer Oracle-Datenbank verschwunden. Werfen wir einen Blick in die betreffende Datenbank. Hierzu kann der graphische Oracle Enterprise Manager oder aber – wie im folgenden Beispiel - SQL*Plus genutzt werden. Wir setzen also ein Select Statement mit SQL*Plus auf die Department-Tabelle [dept], in der die Datensätze der Abteilungen gespeichert sind, ab:

SQL> SELECT * FROM dept;
ABTNR DNAME        LOC
----- ------------ ---------------
   10 ACCOUNTING   NEW YORK
   20 RESEARCH     DALLAS
   30 SALES        CHICAGO
   40 OPERATIONS   BOSTON

Es zeigt sich: Herr Müller hat Recht. Hier gibt es aktuell wirklich keine Abteilung mit der Nummer 50. Betreiben wir ein wenig Forschung: Wie sah der Datenbestand denn am 02.03.2004 um 07:00 Uhr in der Frühe aus?

SQL> SELECT * FROM dept 
2>    AS OF TIMESTAMP
3>    to_timestamp('02-03-2004 07:00:00','dd-mm-yyyy hh24:mi:ss');
DEPTNO DNAME  LOC
------------  --------------- -------------
10 ACCOUNTING NEW YORK
20 RESEARCH   DALLAS
30 SALES      CHICAGO
40 OPERATIONS BOSTON
50 IT         FRANKFURT

Aha! Da sind wir doch schon einen Schritt weiter: Morgens um 7 war die Abteilung 50 also noch vorhanden. Das oben stehende Beispiel zeigt, wie die Syntax von Flashback Query eingesetzt werden kann:

  1. Abfragetext in SQL formulieren und
  2. zusätzlich den historischen Zeitpunkt, zu dem der Datenbestand angezeigt werden soll, mit der Syntax AS OF TIMESTAMP angeben.

Möchte man jetzt herausfinden, wie sich der Datensatz über den Tag verändert hat oder aber wann er genau gelöscht wurde, so kann man mit der Syntax VERSIONS BETWEEN alle Versionen innerhalb des angegebenen Zeitraumes inklusive sämtlicher Änderungen ausgeben lassen:

SQL> SELECT   deptno, dname, loc,
2>            versions_operation, versions_xid, versions_starttime
3>   FROM                 scott.dept
4>   VERSIONS BETWEEN     timestamp minvalue and maxvalue
5>   ORDER BY             deptno, versions_starttime
DEPTNO DNAME       LOC        V VERSIONS_XID     VERSIONS_STARTTIME
------ ----------- ---------- - ------------ ----------------------
    10 ACCOUNTING  NEW YORK
    20 RESEARCH    DALLAS
    30 SALES       CHICAGO
    40 OPERATIONS  BOSTON
    50 IT          FRANKFURT
    50 MARKETING   FRANKFURT   U 1E000A0008000000 02.03.04 09:30:02
    50             FRANKFURT   U 1E000B0008000000 02.03.04 09:31:15
    50             FRANKFURT   D 1E000C0008000000 02.03.04 09:32:20
8 Zeilen ausgewählt

Und siehe da, der Datensatz wurde zunächst um 09:30 Uhr und 2 Sekunden geändert. In Zeile 5 stand in der Spalte [dname] noch der Wert "IT". Zu diesem Zeitpunkt wurde der Name der Abteilung von "IT" auf "Marketing" geändert. Erkennbar ist dies in Zeile 6. Hier steht in der Spalte [versions_operation] ein U wie Update und als neuer Wert der Spalte [dname] der Begriff "MARKETING", während in Zeile 5 noch "IT" zu finden war. Um 09:31 und 15 Sekunden erfolgte das nächste Update: Wieder enthält die Spalte [versions_operation] ein U für Update, der Wert der Spalte [dname] ist nun leer. Die letzte Änderung stammt dann von 09:32 Uhr und 20 Sekunden. Hier wurde der Satz gelöscht. Erkennbar ist dies wieder in der Spalte [versions_operations] am Flag D, das für Delete steht.

In der letzten Abfrage werden mehrere Pseudo Columns angesprochen: [versions_operation], [versions_xid] und [versions_starttime]. Diese Spalten sind nicht physisch in der Tabelle in Form von Spalteninhalten gespeichert. Vielmehr erhalten wir durch sie zusätzliche Informationen, die aus dem internen Data Dictionary der Datenbank stammen. Die Pseudo-Spalte [versions_operation] gibt Auskunft über die Operation, die ausgeführt wurde: I für Insert, U für Update, D für Delete. Unter [versions_xid ] finden wir die interne Transaktionsnummer innerhalb der Datenbank. Diese werden wir gleich noch benötigen. Unter [versions_starttime] ist der Zeitpunkt zu verstehen, ab dem diese Änderung gültig wurde. Dabei handelt es sich um den Zeitpunkt, zu dem die Änderung mit Commit bestätigt wurde.

In unserem Beispiel kann durch Nutzung der zuvor ermittelten Transaktions-ID aus der Spalte [versions_xid] das UNDO- Statement gefunden werden, um die Veränderungen an der Tabelle [dept] wieder rückgängig zu machen. Über die Pseudo-Spalte [version_xid] in der oben genannten Flashback Query konnten wir die Transaktions-ID ermitteln. Die Datenbank-View flashback_transaction_query liefert Informationen über das UNDO-SQL Statement, das zur Transaktion mit der ID '1E000C0008000000' gehört:

SQL> SELECT logon_user, table_name, 
            table_owner, undo_sql
     FROM   flashback_transaction_query
     WHERE  table_owner='SCOTT'
            -- xid = Transaktions-ID
     AND    xid= '1E000C0008000000';
LOGON_USER    TABLE_NAME    TABLE_OWNER    UNDO_SQL
------------------------------------------------------------
SMUELLER    DEPT    SCOTT    
insert into "SCOTT"."DEPT"("DEPTNO","DNAME","LOC") values ('50','UUuuups','Frankfurt');

Ein kleiner Ausflug in Datenbank-Interna: Durch Abfrage der View flashback_transaction_query erhält man die Ergebnisse der Abfrage, die über den Logon-User, die betreffende Tabelle und deren Besitzer sowie das Statement zum Rückgängig-Machen der Transaktion geben. Wer die Augen nicht vor der Spalte [logon_user] verschließt, der wird bemerken, dass ein als SMUELLER angemeldeter Benutzer die Transaktion zum Löschen des Datensatzes durchgeführt hatte. Das klingt doch sehr nach Herrn Müller aus der Personalabteilung. Aber das behalten wir schmunzelnd einfach für uns!

Betrachtet man das Insert Statement aus der Spalte [undo_sql], so fällt auf, dass hier nur das Delete der Zeile, dass durch die letzte Transaktion abgesetzt wurde, rückgängig gemacht wird. Möchte man tatsächlich auf den ursprünglichen Stand von heute früh zurück, so muss man einfach alle undo_sql-Statements in umgekehrter zeitlicher Reihenfolge (also immer das letzte zuerst), verwenden, um die Änderungen schrittweise wieder rückgängig zu machen.

SQL> SELECT   undo_sql
2 >  FROM     flashback_transaction_query
3 > WHERE     table_owner = 'SCOTT'
4 > AND       table_name = 'DEPT'
5 > ORDER BY  commit_timestamp desc
UNDO_SQL
-------------------------------------------------------------------
insert into "SCOTT"."DEPT"("DEPTNO","DNAME","LOC") values ('50','UUuuups','Frankfurt');
update "SCOTT"."DEPT" set "DNAME" = 'MARKETING' where ROWID = 'AAALy6AAEAAAAAOAAA';
update "SCOTT"."DEPT" set "DNAME" = 'IT' where ROWID = 'AAALy6AAEAAAAAOAAA';

Sehr viel leichter lassen sich solche Änderungen mit Oracle DBControl vornehmen. Hier kann man sich – gestützt durch ein graphisches Werkzeug – durch die Masken des Flashback hangeln und mit einem Mausklick einen Datensatz wiederherstellen. Auch wenn das Vorgehen mit dem DBControl sehr viel bequemer ist, sollte man doch die Hintergründe verstanden haben. In schweren Problemfällen kann dies das Finden einer Lösung sehr viel einfacher machen.

Im Vergleich zur Flashback Table-Technologie, die im nächsten Abschnitt genauer beschrieben wird, stellt diese Technik eine Alternative bei versehentlichen oder fehlerhaften Änderungen an einzelnen Tabellendaten dar. Neben dem Zeitpunkt via "AS OF TIMESTAMP" oder "VERSIONS BETWEEN" kann auch die Oracle System Change Number verwendet werden. Diese ist sehr viel genauer als ein Timestamp.

Die System Change Number (auch als SCN bezeichnet) ist ein interner Transaktionszähler und vergleichbar einer Auftragsnummer in einem Auftragsbearbeitungssystem. Bei jeder Bestätigung einer Datenänderung durch ein Commit einer Transaktion wird intern in der Datenbank eine eindeutige System Change Number hochgezählt. Diese wird in den Transaktionsprotokollen – unter Oracle sind das die "Redo Logs" – aber auch im Header aller Datenbankfiles verzeichnet. Die SCN hat während eines Datenbankrecovery, aber auch im Kontext von Lesekonsistenz eine zentrale Bedeutung. Diese eindeutige Transaktionsnummer kann in der folgenden Syntax verwendet werden:

SELECT deptno, dept, dname
  FROM scott.dept
  VERSIONS BETWEEN
  SCN 568394 AND 568410
  WHERE deptno = 50;

Mit dieser Syntax kann entweder eine feste SCN verwenden oder minvalue und maxvalue als Variable einsetzen. minvalue zeigt das älteste Before-Image, das für diesen Datensatz noch im UNDO-Tablespace vorhanden ist. Bei maxvalue handelt es sich um die letzte Änderung. Die Syntax mit "VERSIONS BETWEEN SCN minvalue AND maxvalue" zeigt also alle noch im UNDO-Bereich gespeicherten Variationen aller vom SQL-Statement betroffenen Datensätze an. Alternativ kann auch eine einzelne SCN benannt werden.

Flashback Table anwenden: Zurücksetzen des Datenbestandes einer Tabelle

Im obigen Beispiel wurde die Datenmanipulation eines einzelnen Datensatzes verfolgt. Dieser konnte bei Bedarf über ein Undo-SQL wieder in den ursprünglichen Zustand zurückgesetzt werden. Wurden in einer Tabelle sehr viele Sätze verändert, ist es unter Umständen leichter, die gesamte Tabelle zurückzusetzen. Oracle stellt hierfür die folgende Syntax bereit:

FLASHBACK TABLE dept 
TO TIMESTAMP to_timestamp('02.03.2004 09:30','dd.mm.yyyy hh24:mi');

Das Zurücksetzen einer ganzen Tabelle birgt jedoch einige Gefahren in Bezug auf Datenkonsistenz: Wurden in der Mitarbeitertabelle alle Mitarbeiter der Abteilung 50 sowie in der Abteilungstabelle die Abteilung mit der Nummer 50 gelöscht, erhält man beim alleinigen Zurücksetzen der Mitarbeitertabelle inkonsistente Daten. In solchen Fällen müssen immer alle voneinander abhängigen Tabellen synchron zurückgesetzt werden. Im letzten Beispiel wären also beide Tabellen zu reseten: Mitarbeiter- und Abteilungstabelle.

Genauer als ein Zeitstempel ist die System Change Number:

FLASHBACK TABLE dept 
TO SCN 23491;

Möchte man auf eine bestimmte Transaktion zurücksetzen, so lässt sich dies entweder über Logminer-Technologie oder – einfacher noch – über die View flashback_transaction_query prüfen. Die Spalte [commit_scn] gibt die System Change Number an, zu der eine Transaction bestätigt wurde. Ein Beispiel: Alle Zeilen der Tabelle emp des Benutzers scott wurden gelöscht. Die exakte Zeit dieser ungewollten Datenänderung ist nicht bekannt. Wird die Tabelle über einen Zeitstempel zurückgesetzt, so ist die Wahrscheinlichkeit recht groß, dass entweder nicht weit genug oder viel zu weit zurückgerollt wird. Die System Change Number dagegen erlaubt ein transaktionsgenaues Zurücksetzen der Tabelle. Dazu wird zunächst über die View flashback_transaction_query die relevante System Change Number ermittelt, mit der der Löschvorgang auf scott.emp in der Datenbank festgeschrieben wurde:

SQL> delete from scott.emp;
14 rows deleted.
SQL> commit;
Commit complete.

Über flashback_transaction_query wird die System Change Number ermittelt:

SQL> select max (commit_scn) 
2    from flashback_transaction_query
3    where table_owner = 'SCOTT'
4    and table_name = 'EMP'
5     and operation='DELETE';
MAX(COMMIT_SCN)
---------------
         677939

Für ein Flashback muss der Wert SCN -1 verwendet werden, da ja auf die letzte Transaction vor dieser System Change Number zurückgesetzt werden muss. Da das Delete-Statement mit System Change Number 677939 commitet wurde, muss hier also auf 677938 zurückgerollt werden:

SQL>  flashback table scott.emp to scn 677938;
Flashback complete.
Zurücksetzen der Tabelle auf die ermittelte System Change Number
Alle 14 Zeilen sind danach wiederhergestellt:
SQL> select count(*) from scott.emp;
COUNT(*)
----------
        14

Natürlich gibt es auch Hürden: Damit Flashback Table funktioniert, muss für die betreffende Tabelle Row Movement aktiviert werden. Ist dies nicht der Fall, antwortet die Oracle Engine mit folgender Fehlermeldung:

SQL>  flashback table scott.emp to scn 677938;
ERROR at line 1:
ORA-08189: cannot flashback the table because row movement is not enabled
SQL> alter table scott.emp enable row movement;
Table altered.
SQL>  flashback table scott.emp to scn 677938;
Flashback complete.

Row Movement kann auch im Nachhinein noch aktiviert werden. Auch dann funktioniert ein Flashback einer Tabelle zu einem Zeitpunkt vor Aktivierung des Row Movements.
Zudem muss SQL*Plus des Oracle 10g Releases eingesetzt werden. Die Fehlermeldung früherer Versionen wird durch das CLI verursacht;

SQL> flashback table scott.emp to scn 677938;
SP2-0734: Unbekannter Befehl ab "flashback ..."

Flashback Query und Flashback Table sind wunderbar für das Monitoring bzw. zum Wiederherstellen veränderter und gelöschter Datenbestände geeignet. Was aber, wenn jemand versehentlich eine ganze Tabelle gelöscht hat? Flashback Query funktioniert nur, wenn an der betreffenden Tabelle keine Strukturänderungen vorgenommen wurden. Wurde eine ganze Tabelle mit einem DROP TABLE Statement gelöscht, funktioniert Flashback Query also nicht mehr.

Flashback Drop anwenden: Gelöschte Tabellen wiederherstellen

Wird eine Tabelle gelöscht, so war diese bis Version 9i unwiederbringlich verloren. Einzige Möglichkeit war die relativ aufwändige Wiederherstellung aus einem validen Backup. Mit dem neuen Release 10g haben die Oracle-Entwickler eine ebenso einfache wie hilfreiche Erweiterung des Flashback einbezogen: Flashback Table. Statt die Tabelle "hart" zu löschen, wird sie intern in den Recycle Bin verschoben. Das geht – unabhängig von der Größe der zu löschenden Tabelle – unglaublich schnell, da intern nur ein paar geringfügige Änderungen im Data Dictionary der Datenbank vorgenommen werden. Das Konzept ist nicht neu. Im Grunde handelt es sich um einen ganz ähnlichen Vorgang wie die Nutzung des Papierkorbs unter Windows. Ein Beispiel:

DROP TABLE dept CASCADE CONSTRAINTS;

Mit diesem Befehl wird die Tabelle [dept] gelöscht. Die Option CASCADE CONSTRAINTS bewirkt, dass dabei auch nicht auf referenzielle Integrität Rücksicht genommen wird. Stattdessen werden Foreign Key Constraints, soweit betroffen, gleich mit gelöscht. Mit dem folgenden Befehl lässt sich die Tabelle wieder herstellen:

FLASHBACK TABLE dept to BEFORE DROP;

Eine Warnung noch: Obwohl die Wiederherstellung so leicht und schnell funktioniert, sollte man Tests mit dem Undrop natürlich nur in Testumgebungen durchführen. Auch Objekte des Recycle Bin bleiben dort nicht beliebig lange bestehen. Bei einer Reorganisation, einer Größenänderung des Tablespaces sowie bei Überschreitung der Speicherbegrenzung des Benutzers wird der Recycle Bin entleert. Darüber hinaus gibt es noch den Purge-Befehl, der ein Objekt gezielt aus dem Recycle Bin entfernt. Zwei Beispiele zum "Purgen":

DROP TABLE dept PURGE; -- Löscht die Tabelle endgültig
PURGE RECYCLEBIN;      -- Leert den Recycle Bin

Den Inhalt des Recycle Bin kann man sich in SQL*Plus auch mit dem Befehl show recyclebin ausgeben lassen:

SQL> show recyclebin
ORIGINAL NAME  RECYCLEBIN NAME     OBJECT TYPE  DROP TIME
-------------- ------------------- ------------ -------------------
DEPT           RB$$48444$TABLE$0   TABLE        2004-03-02 10:29:40

Datenbankadministratoren können prüfen, welche Daten derzeit im Recycle Bin vorliegen, indem die Data Dictionary View dba_recyclebin bzw. user_recyclebin abgefragt werden. Hier sind alle Informationen über Objektnamen, Typen und Löschzeitpunkt zu finden. Einfache Benutzer können mit dem Befehl show recyclebin den Inhalt ihres Papierkorbes zur Anzeige bringen. Die Handhabung im Oracle Enterprise Manager ist natürlich viel einfacher, als das mühselige Werkeln mit Scripten und SQL-Befehlen.

Die Funktionalität des Recycle Bin kann ausschließlich für Objekte angewendet werden, die in einem Locally Managed Tablespace gespeichert wurden. Data Dictionary Managed Tablespaces sind also ausgenommen. Ebenfalls ausgeschlossen sind Objekte, die im System Tablespace gespeichert werden.

Da dem Recycle Bin keine feste Größe und keine Aufbewahrungsdauer zugewiesen werden kann, gibt es keine Sicherheit für den Zeitraum, den ein Objekt im Recycle Bin zur Verfügung steht. Abhängig von der Systemaktivität und der Speicherauslastung kann diese Zeitspanne stark variieren.

Gegen Objekte des Recycle Bin können auch weiterhin Abfragen abgesetzt werden. DML- oder DDL-Statements sind jedoch nicht gestattet. Es können also keine Daten eingefügt, gelöscht oder verändert werden. Auch der Aufbau des Objektes im Recycle Bin kann nicht geändert werden.

Flashback Query auf Objekte des Recycle Bin ist möglich. Jedoch muss der etwas kryptische Systemname der Tabelle im Recycle Bin genutzt werden. Der Originalname kann hier nicht mehr verwendet werden.

Wird eine Tabelle gelöscht, so werden abhängige Objekte wie Indizes, Constraints, LOB Segmente und Trigger ebenfalls entfernt. Bei der Wiederherstellung der Basis-Tabelle sollten diese abhängigen Objekte ebenfalls automatisch wiederhergestellt werden. Erfahrungsgemäß funktioniert das nicht immer. So können zum Beispiel Indizes aufgrund von Speicherplatzmangel bereits aus dem Recycle Bin entfernt worden sein. Nach Wiederherstellung einer Tabelle sollte daher die Vollständigkeit aller abhängigen Datenbankobjekte geprüft werden.

Weitere Einschränkungen sind:

  • Referentielle Constraints bestehen nach einer Wiederherstellung einer Tabelle aus dem Recycle Bin nicht mehr. Diese müssen erneut implementiert werden.
  • Daten von Tabellen, die mit Fine Grained Auditing (FGA) bzw. im Rahmen von Policies einer Virtual Private Database (VPD) geschützt wurden, sind im Recycle Bin nicht mehr gesichert.
  • Partitionierte Index Organized Tables können derzeit nicht über den Recycle Bin geschützt werden.

Flashback Database anwenden: Zurücksetzen ganzer Datenbanken

Manchmal genügt es nicht, einzelne Tabellen zurückzusetzen. Hier bietet Flashback Database Hilfe. Flashback Database ist sicherlich die weitaus mächtigste Möglichkeit des Flashback. Hiermit wird die gesamte Datenbank in einen historischen Zustand zurückgefahren. Dies betrifft alle Objekte eines jeden Users dieser Datenbank. Auf einzelne Benutzer lässt sich diese Form des Zurücksetzens nicht beschränken. Das Ergebnis entspricht dem eines konventionellen Point-in-Time Recovery. Doch der Vorgang an sich ist weit weniger kompliziert und benötigt wesentlich weniger Zeit.

Der Befehl zum Zurücksetzen der Datenbank ist denkbar einfach: Er lautet einfach flashback database. Zusätzlich wird der Zeitpunkt auf den zurückgerollt werden soll in Form eines Zeitstempels oder der System Change Number übergeben.

Der Befehl flashback database kann nur im Mount-Zustand der Datenbank erfolgreich ausgeführt werden. Abschließend muss die Datenbank mit einem Reset der Redo Logs geöffnet werden.

Die allgemeine Syntax lautet:

  FLASHBACK DATABASE TO SCN <scn>;

oder

  FLASHBACK DATABASE TO TIMESTAMP <timestamp>

Hier ein praktisches Beispiel:

-- 1. Herunterfahren der Datenbank
SQL> SHUTDOWN IMMEDIATE;

-- 2. Hochfahren in den Mount Modus
SQL> STARTUP MOUNT;      

-- 3. Flashback der Datenbank
SQL> FLASHBACK DATABASE TO TIMESTAMP
2    to_timestamp ('02.03.2004 09:30:00','dd.mm.yyyy hh24:mi:ss');

-- 4. Datenbank mit open resetlogs öffnen
SQL> ALTER DATABASE OPEN RESETLOGS;

Die Datenbank befindet sich dann mit allen Daten sämtlicher Datenbankbenutzer auf dem Stand des im Flashback-Befehl angegebenen Zeitpunktes, im Beispiel also auf 09:30 Uhr und 0 Sekunden.

Durch gelöschte Tabellen oder versehentlich durchgeführte truncate-Kommandos ausgelöste Probleme können mit diesem Kommando rückgängig gemacht werden. Wichtig ist die Tatsache, dass die gesamte Datenbank durch flashback database physikalisch in einen früheren, konsistenten Zustand zurückgesetzt wird und mit der Option resetlogs geöffnet werden muss.

Im folgenden Beispiel wird das versehentliche Löschen eines Users rückgängig gemacht.

Schritt 1: Prüfen des Benutzers in der Datenbank
Die Data Dictionary View dba_users gibt Auskunft über die in der Datenbank existierenden Datenbank-Benutzer.

SQL> SELECT username FROM dba_users;
USERNAME
------------------------------
FLASHBACK
HR
MDDATA
OE
SH
SCOTT

Der Benutzer HR existiert derzeit noch. Über die View dba_objects kann zudem geprüft werden, welche Objekte dieser Benutzer besitzt.

SQL> SELECT owner, object_type, object_name 
2        FROM   dba_objects
3        WHERE  owner = 'HR';
OWNER      OBJECT_TYPE          OBJECT_NAME
---------- -------------------- ------------------------------
HR         TABLE                REGIONS
HR         INDEX                REG_ID_PK
HR         TABLE                COUNTRIES
HR         INDEX                COUNTRY_C_ID_PK
HR         TABLE                LOCATIONS
HR         INDEX                LOC_ID_PK
...
HR         PROCEDURE            SECURE_DML
HR         TRIGGER              SECURE_EMPLOYEES
HR         PROCEDURE            ADD_JOB_HISTORY
HR         TRIGGER              UPDATE_JOB_HISTORY
34 rows selected.

Schritt 2: Löschen des Users
Zunächst wird der Benutzer hr mit all seinen Objekten kaskadierend aus der Datenbank gelöscht.

SQL > DROP USER hr CASCADE; 
User dropped

Schritt 3: Prüfen, ob der User HR noch existiert
Über die View dba_users kann geprüft werden, welche Benutzer in der Datenbank derzeit existieren.

SQL> SELECT username FROM dba_users;
USERNAME
------------------------------
FLASHBACK
MDDATA
OE
SH
SCOTT

Der Benutzer hr wurde erfolgreich gelöscht und wird nicht mehr angezeigt. Auch seine Objekte wurden aus der Datenbank entfernt.

SQL> SELECT owner, object_type, object_name 
2        FROM   dba_objects
3        WHERE  owner = 'HR';
no rows selected.

Schritt 4:  Flashback Database absetzen
Durch das flashback database-Kommando wird der Zustand vor dem Löschen des Users wiederhergestellt:

SQL>STARTUP MOUNT
Database mounted.

SQL>FLASHBACK DATABASE TO SCN 11359846;
Flashback complete.

SQL> ALTER DATABASE OPEN RESETLOGS;
Database altered.

Schritt 5: Prüfen des Benutzers und seiner Objekte in der Datenbank
Der Benutzer hr ist nun wiederhergestellt:

SQL> SELECT username FROM dba_users;
USERNAME
------------------------------
FLASHBACK
HR
MDDATA
OE
SH
SCOTT

Auch die Objekte des Benutzers hr existieren nun wieder und befinden sich im Zustand vor dem Löschen des Benutzers hr:

SQL> SELECT owner, object_type, object_name 
2        FROM   dba_objects
3        WHERE  owner = 'HR';
OWNER      OBJECT_TYPE          OBJECT_NAME
---------- -------------------- ------------------------------
HR         TABLE                REGIONS
HR         INDEX                REG_ID_PK
HR         TABLE                COUNTRIES
HR         INDEX                COUNTRY_C_ID_PK
HR         TABLE                LOCATIONS
HR         INDEX                LOC_ID_PK
...
HR         PROCEDURE            SECURE_DML
HR         TRIGGER              SECURE_EMPLOYEES
HR         PROCEDURE            ADD_JOB_HISTORY
HR         TRIGGER              UPDATE_JOB_HISTORY
34 rows selected.

Dieses Konzept kann ebenfalls in Verbindung mit der Primary- und Standby-Datenbank verwendet werden. Bei logischen Korruptionen ist es z. B. nicht mehr länger notwendig eine Verzögerung mithilfe der DELAY-Option für das Anwenden der Log-Dateien zu verwenden. Die Primary Datenbank kann mit flashback database zurückgesetzt werden und diese Änderung wird an die Standby-Datenbank propagiert.

Die Handhabung der verschiedenen Flashback-Möglichkeiten ist also recht einfach. Logische Fehler, die durch Benutzerfehler, fehlerhafte Software oder ungewollte Administrationskommandos entstanden sind, können mit Flashback in kürzester Zeit und ohne längere Ausfallzeiten behoben werden. Trotzdem sollte man nicht leichtsinnig werden. Ein Flashback bedeutet häufig Datenverlust, da Transaktionen, die nach dem Flashbackzeitpunkt erfolgten, ebenfalls zurückgerollt werden.

Bestimmen des aktuellen Recovery Window
Wie weit man eine Datenbank mit flashback database zurücksetzen kann, hängt vom Transaktionsvolumen und dem Speicherplatz ab, der als Flash Recovery-Bereich für Block Images zur Verfügung steht. Mit der View v$flashback_database_log läßt sich herausfinden, bis zu welcher System Change Number das System zurückgefahren werden könnte.

SQL> select oldest_flashback_scn, oldest_flashback_time
  2  from v$flashback_database_log;
OLDEST_FLASHBACK_SCN OLDEST_FLASHBACK_TIME
-------------------- ---------------------
              771453   22.06.2004 11:25:06

Abfrage des Zeitraumes, für den ein Flashback Database vorgenommen werden kann
Genügt dieses Recovery Window den Anforderungen nicht, so ist der Flash Recovery Bereich zu vergrößern.

Performance Tuning für Flashback Database
Das Schreiben der Flashback Logs schafft zusätzlichen Overhead, der sich bei Oracle 10g in  bis zu ca. 3 Prozent Performance Verlust ausdrückt. Hintergrund dieser Performance Einbuße ist, dass zusätzlich zur "normalen" Datenbankaktivität geänderte Blöcke aus dem Speicher in die Flashback Logs geschrieben werden müssen. In großen Produktionsdatenbanken empfiehlt es sich daher, folgendes zu beachten:

  • Vermeiden Sie – wenn möglich – File Caching des Operating Systems für diesen Bereich. Dateien, die in das Flash Recovery Area geschrieben werden, sind meist sehr groß. File Caching ist hier meist nicht sehr effizient und führt unter Umständen zu einem nicht unerheblichen Overhead an CPU-Zeit. Es empfiehlt sich daher, für den Flash Recovery-Bereich entweder Oracles Automatic Storage Management oder aber Direct I/O einzusetzen.
  • Nutzen Sie schnellen Storage und ein schnelles Filesystem für die Flash Recovery Area. Gerade für Datenbanken mit hohen Transaktionsraten lohnt es, über mehrere physikalische Disks den Durchsatz für diesen Bereich zu erhöhen.
  • Entgegen anderer Empfehlungen sollte in großen Produktionsdatenbanken bei Einsatz von Flashback Logs der Log Buffer auf eine Größe von mindestens 8 MB gesetzt werden. Dies stellt sicher, dass für das Schreiben der Flashback Logs der maximal mögliche Memory (normalerweise sind das 16 MB) für das Schreiben der Flashback Logs verwendet wird.

Der Overhead, der durch das Schreiben der Flashback Logs entsteht, hängt vom Workload und den Transaktionsraten der Datenbank ab. Während ändernde Transaktionen Schreibvorgänge auch im Flashback-Bereich verursachen, haben Abfragen, die keine Daten ändern, keinen Einfluss.

Resümee

Flashback zielt in erster Linie auf Benutzerfehler. Hat ein Benutzer versehentlich Daten gelöscht oder in unbeabsichtigter Weise verändert, so gab es früher nur eine Möglichkeit: Die oft aufwändige Wiederherstellung über Backup. Mit Flashback können geänderte oder gelöschte Daten entweder mit SQL-Befehlen oder aber über den intuitiv bedienbaren Oracle Enterprise Manager (OEM) wiederhergestellt werden. Flashback funktionierte bereits in der 10g Beta recht zuverlässig und deckt alle wesentlichen logischen Fehlertypen ab. Nur die View [flashback_transaction_query] zeigt noch einige Fehler: Updates werden gelegentlich nicht angezeigt; die Abfrage der View dauert unverhältnismäßig lang.

Generell gibt es seit Oracle 10g diverse Optionen zu Flashback:

  • Flashback Query gibt es seit Oracle 9i und wurde in 10g auf Flashback Table erweitert,
  • Flashback Drop steht ab 10g zur Verfügung,
  • Flashback Database wurde ebenfalls mit Oracle 10g eingeführt.

Alle lassen sich jederzeit in ein und derselben Datenbank anwenden. Die Architektur, Implementierung und Funktionalität ist jeweils etwas unterschiedlich. Flashback Query nutzt den Undo Tablespace, Flashback Table den Recycle Bin und Flashback Database verwendet archivierte Redo Logs und Flashback Logs.

Dies ist der dritte Teil einer Artikelserie zu Oracle Hochverfügbarkeit. Die beiden vorherigen Artikel befassen sich mit

Hochverfügbarkeit und Downtime: Eine Einführung

Hochverfügbarkeit und Downtime: Metriken.

Autorin

Andrea Held

Andrea Held ist technische Architektin und Autorin von Fachartikeln und Büchern, darunter "Der Oracle DBA", "Oracle New Features" und "Oracle Hochverfügbarkeit". Ihr Schwerpunkt: Hochverfügbare Datenbanksysteme.
>> Weiterlesen
Bücher der Autorin:

botMessage_toctoc_comments_9210