Für die Funktion von Flashback Database schreibt die Oracle Datenbank sogenannte Flashback Logs in die Flash Recovery Ares (10.2, 11.1) bzw. Fast Recovery Area (11.2). In diesen Flashback Logs werden "preImage" Blöcke der geänderten Datenbankdateien abgelegt und zusätzlich alle 30 Minuten ein sogenannter Flashback Marker Record geschrieben. Dieser Flashback Marker Record enthält einen Zeitstempel bzw. eine SCN, der bzw. die Auskunft darüber gibt, von wann die frühest aufgezeichneten geänderten Blöcke im entsprechenden Flashback Log sind.

Wird nun ein Flashback Database durchgeführt, so wird mit Hilfe des Flashback Marker Records ermittelt, welcher Zeitpunkt vor dem gewünschten Flashback Zeitpunkt liegt. Die Datenbank verwendet dann alle PreImage Blöcke vom Zeitpunkt des entsprechenden Flashback Marker Records (auch wenn dieser früher als der gewünschte Zeiptunkt ist) und überschreibt damit die Daten im Datenfile. Um dann auf die vom Benutzer gewünschte SCN zu kommen, werden zusätzlich die archivierten Redologs benötigt und mit deren Hilfe ein Recovery durchgeführt. Das Initialisierungsparameterfile (SPFile oder init.ora) ist von einem Flashback Database nicht betroffen.

Generell wird beim Schreiben der Flashback Logs allerdings unterschieden, ob Flashback Database generell eingeschaltet worden ist oder ob es implizit durch das Setzen eines GRP eingeschaltet wurde. Dies hat durchaus Auswirkungen auf die Informationen, die in den Flashback Logs gespeichert werden, genauer gesagt auf die Größe der Flashback Logs:

Ist das generelle Flashback Logging der Datenbank eingeschaltet, so markiert das Schreiben eines Flashback Marker Records jeweils einen speziellen Zeitpunkt. Ab diesem Zeitpunkt wird von jedem danach geänderte Block (auch die Blöcke des UNDO Tablespaces), das "preImage" in den Flashback Logs genau ein mal abgelegt. Wird ein Datenbank Block in kurzen Zeitabständen mehrfach geändert, so führt dies nicht dazu, dass der Block nochmals in den Flashback Logs gespeichert wird, da diese Informationen ja bereits in den archivierten Redologs zu finden ist. Jeder Flashback Marker Record ist praktisch ein Neubeginn, ab dem der Prozess neu startet. Das Setzen eines Rücksetzpunktes (egal ob garantiert oder nicht) hat auf dieses Standard Verhalten keinen direkten Einfluss (ausser, dass ein GRP wie ein Flashback Marker Record ausserhalb der 30 Minuten wirkt). Da die Flashback Marker Records im Normalfall im Zeitabstand von 30 Minuten (nicht parametrisierbar) geschrieben werden, beginnt der Prozess des Schreibens der Flashback Informationen praktisch jedes mal neu. Die Flashback Logs werden dabei rollierend verwendet, sobald die in der init.ora spezifizierte Flashback Zeit (db_flashback_retention_target) überschritten worden ist.

Genau diese Rollierung der Flashback Logs, ist aber auch die Ursache für den Effekt, dass die gesetzte Flashback Zeit nicht zu 100% eingehalten wird. Die Datenbank ermittelt beim erstmaligen Aktivieren der Flashback Database Funktion die Größe und Anzahl der Flashback Logs. Je nach gewählter Flashback Zeit und Änderungsrate wird unterschiedlich viel Plattenplatz benötigt - je nach gewünschter Vorgabe kann das auch die Größe der Datenbank übersteigen. Ist die Zielvorgabe erreicht (und genügend Plattenplatz vorhanden), beginnt die Datenbank mit dem ersten Log von neuem. Sollte sich nun nach einiger Zeit die Änderungsrate der Datenbank (Anzahl Blöcke) verändern, so wir die Datenbank die Flashback Logs immer noch rollieren und zumindest den ältesten Flashback Marker Record überschreiben. Erst dann stellt die Datenbank fest, dass die gewünschte Flashback Zeit nicht eingehalten werden kann und wird zusätzliche Flashback Logs anlegen. Dies bedeutet, dass im schlimmsten Fall db_flashback_retention_target um bis zu 30 Minuten (Intervall der Flashback Marker Records) unterschritten wird. Deswegen empfiehlt es sich, die Zeitdifferenz bei der Berechnung der gewünschten Flashback Zeit zu berücksichtigen.

Wird Flashback Logging implizit durch das Setzen eines GRP aktiviert (und damit das Schreiben der Flashback Logs gestartet) - was seit Oracle 11.2 auch online passieren kann, so sieht das Schreiben der Flashback Logs anders aus: Der garantierte Rücksetzpunkt übernimmt in diesem Fall die Funktion des Flashback Marker Records. Ab diesem Zeitpunkt wird von jedem Block jeweils nur genau ein "preImage" Block in die Flashback Logs geschrieben. Da aber auch hier die Blöcke des UNDO Tablespace enthalten sind, kann man dies an der Größe der Flashback Informationen nicht sofort erkennen, denn in der Anfangszeit wachsen die Flashback Informationen überproportional. Im Endeffekt können bei der Verwendung eines bloßen GRP die Flashback Logs aber niemals größer werden als die belegte Datenbank Größe.

Darum hat die Implizite Aktivierung von Flashback Database über einen GRP gerade für Testsysteme mehrere Vorteile:

• Man kommt immer auf den gewünschten Zeitpunkt zurück
• Das Zurücksetzen geht schneller, da nur minimal Informationen aus archivierten Redologs benötigt werden
• Der benötigte Plattenplatz ist definiert (maximal = DB Größe)

Allerdings besitzt dieses Vorgehen auch einen Nachteil: Steht nicht genügend Plattenplatz zur Verfügung, stellt die Testdatenbank die weitere Arbeit ein, bis mehr Plattenplatz zur Verfügung steht.

Folgende Voraussetzungen sind notwendig, um Flashback Database verwenden zu können:

• Die Datenbank muss sich im Archivelogmodus befinden.
• Die Flash bzw. Fast Recovery Area muss über db_recovery_file_dest definiert sein

Das sind die einzigen beiden Voraussetzungen um mit Flashback Database direkt loslegen zu können. Insbesondere, wenn man nur mit einem GRP arbeiten möchte. Allerdings gibt es noch 2 zusätzliche Parameter, bei denen auf die richtige Größe geachtet werden sollte: db_recovery_file_dest_size und db_flashback_retention_target. Insbesondere der letzte kommt zum tragen, wenn Flashback Database generell (ohne GRP) verwendet wird.

• DB_FLASHBACK_RETENTION_TARGET - definiert das Zeitintervall in Minuten, während dessen ein Rücksetzen der Datenbank ohne Verwendung eines GRP möglich ist. Der Parameter sollte mindestens auf 60 Minuten für Standy Systeme stehen, damit eine Reinstanziierung der Datenbank (Aktivierung einer Standby nach einem Failover ohne neu aufsetzen zu müssen) möglich ist, bzw. auf die Zeit, in der die Datenbank z.B. wegen eines Benutzerfehlers zurückgestellt werden soll.
  Aus den oben erwähnten Gründen empfiehlt es sich, 30 Minuten zur beabsichtigten Zeit hinzuzufügen. Ab 11g werden immer mindestens 60 Minuten in den Flashback Logs gehalten, auch wenn die Retention Zeit geringer angegeben ist.
• DB_RECOVERY_FILE_DEST_SIZE - die Größe der Fast Recovery Area. Ist sie zu klein gewählt, kann db_flashback_retention_target nicht garantiert werden, da bei Platzmangel die Flashback Logs entfernt werden. Wird ein GRP verwendet, so führt eine zu kleine FRA zum Anhalten der Datenbank, bis wieder mehr Platz zur Verfügung steht oder der GRP gelöscht wird.
  
  Um den benötigten Platz für Flashback Logs in der FRA zu bestimmen, kann am einfachsten Database Flashback eingeschaltet werden und dann nach kurzer Zeit (2-3 Stunden) in den Statistiken zu Flashback Database nachgeschaut werden:

SQL> select * from V$FLASHBACK_DATABASE_STAT order by begin_time;
BEGIN_TIM END_TIME  FLASHBACK_DATA    DB_DATA  REDO_DATA ESTIMATED_FLASHBACK_SIZE
--------- --------- -------------- ---------- ---------- ------------------------
04-JUN-12 05-JUN-12       23896064   35201024   27864576                161562624
04-JUN-12 05-JUN-12        3883008    4866048    1534976                152051712
04-JUN-12 06-JUN-12        4136960    5152768    1490944                145612800
05-JUN-12 06-JUN-12        3186688    4415488    1172992                138092544
05-JUN-12 06-JUN-12        3629056    4743168    1303040                133079040
05-JUN-12 06-JUN-12        3678208    4890624    1433600                129073152

Wie man sieht schwankt der geschätzte Wert, je nach Aktivität auf der Datenbank. Um den Wert von "ESTIMATED_FLASHBACK_SIZE" sollte dann die FRA vergrößert werden - bitte nicht explizit auf den Wert setzen, da in die FRA im Normalfall auch die archivierte Redologs und Backups der Datenbank gespeichert werden.

Handelt es sich um eine Testdatenbank und man verwendet nur GRP, ist eine Schätzung nicht notwendig und man kann einfach die Größe der Datenbank als Maximalwert für die Flashback Logs annehmen. Ergo wäre die FRA 3x so groß wie die DB: 1x Backup (Imagekopie) + 1x Archivelogs + 1x Flashback Logs.

Ein Flashback Database kann auch über Inkarnationsgrenzen (nach einem OPEN Resetlogs) funktionieren und bietet deswegen viele Möglichkeiten. Allerdings gibt es einige Einschränkungen, die auch mit Flashback Database nicht abgefangen werden können:

• NOLOGGING Operationen sind nicht nur für ein Backup eine schlechte Idee, auch für Flashback Database gibt es Restriktionen, da für das Recovery auf einen bestimmten Zeitpunkt Archive Logs benötigt werden. Die gute Nachricht ist allerdings, dass beim Setzen eines GRP (garantiert!) und Zurücksetzen auf diesen GRP auch Nologging Operationen zurückgesetzt werden können, da hier beim Flashback Archivelogs in nur sehr beschränktem Maße benötigt werden. Ein Rücksetzen auf einen anderen Zeitpunkt (nach dem GRP) oder auf einen nicht garantierten Rücksetzpunkt kann allerdings bei den von NOLOGGING betroffenen Objekten zu Korruption führen
• Es ist durchaus möglich, einzelne Tablespaces vom Flashback auszuschließen. Diese können dann aber auch nicht zurückgesetzt werden und müssen für das Flashback auf Read-Only gesetzt werden
• Ein Shrink oder ein Drop eines Datenfiles kann mit Flashback Database nicht zurückgesetzt werden und verhindert häufig das Flashback. Deswegen sollten diese Operationen nicht zu Zeiten passieren, in denen ein Flashback Database wahrscheinlich ist.
• Mediafehler (korrupte Blöcke auf Platte) oder gelöschte Datenfiles eines Tablespaces lassen sich mit Flashback Database nicht reparieren

Sind die Voraussetzungen erfüllt, kann Flashback Database während des laufenden Betriebes aktiviert werden:

SQL> alter database flashback on

Database altered.

Oder implizit über das Setzen eines GRP:

SQL> create restore point SolbachGRP guarantee flashback database;

Restore point created.

Das funktioniert online allerdings erst seit Oracle 11.2 und kann auch dort unter Umständen fehlschlagen (abhängig vom verfügbaren Memory). Alternativ kann wie in 10.2 oder 11.1 Flashback Database im Mount Status (nach einem sauberen Shutdown) der Datenbank aktiviert werden.

Ob Flashback Database nun generell eingeschaltet ist oder nur durch die Verwendung eines GRP kann man v$database entnehmen:

SQL> SELECT flashback_on, log_mode FROM v$database;

FLASHBACK_ON       LOG_MODE
------------------ ------------
RESTORE POINT ONLY ARCHIVELOG

Das eigentliche Zurücksetzen der Datenbank funktioniert immer nur im Mount Status der Datenbank und kann auf eine bestimmte SCN oder einen Timestamp passieren. Hat man Flashback Database implizit über einen GRP aktiviert, funktioniert ein Flashback nur auf einen GRP, nicht aber auf eine andere Zeit resp. SCN. bzw. nicht garantierten Restorepoint, wie folgende Fehlermeldung zeigt:

SQL> startup mount;
ORACLE instance started.

Total System Global Area  431038464 bytes
Fixed Size                  1344672 bytes
Variable Size             297798496 bytes
Database Buffers          125829120 bytes
Redo Buffers                6066176 bytes
Database mounted.

SQL> flashback database to SCN 431100
flashback database to scn 431100
*
ERROR at line 1:
ORA-38726: Flashback database logging is not on.

SQL> flashback database to restore point solbachgrp;

Flashback complete.

SQL> alter database open resetlogs;

Database altered.

Je nach Größe der Flashback Logs und benötigtem Recovery kann das Flashback der Datenbank durchaus einige Zeit dauern (aber signifikant kürzer, als ein PITR eines Backups). Um eine ungefähre Vorstellung der benötigten Zeit zu bekommen, kann v$session_longops abgefragt werden:

SQL> select * from v$session_longops where opname like 'Flashback%';

Ebenfalls gibt es die Möglichkeit über den Initialisierungsparamter _FLASHBACK_VERBOSE_INFO=TRUE ein Tracefile für Flashback Database Operation zu generieren. Das ist aber wegen der Performanceimplikation nicht generell zu empfehlen und sollte nur aus Interesse und in Ausnahmefällen gesetzt werden.

Nun wurde bisher schon von garantierten Rücksetzpunkten (GRP) geredet. Aber gibt es auch andere?

Ja: Ein normaler Rücksetzpunkt funktioniert aber letztendlich nur wie eine benannte SCN. Das heißt, anstatt sich sich eine SCN zu merken und aufzuschreiben, wird ein Rücksetzpunkt gesetzt und man kann das Flashback der Datenbank mit dessen Namen ausführen. Die gesetzten Rücksetzpunkte mit SCN und verbrauchtem Flashback Platz kann man v$restore_points entnehmen.

SQL> select * from v$restore_point;

     SCN INCARNATION# GUA STORAGE_SIZE TIME                             RESTORE_POINT_TIME PRE NAME
-------- ------------ --- ------------ -------------------------------- ------------------ --- ---------------
  397371            2 YES     88162304 05-JUN-12 06.51.32.000000000 PM                     YES TEST
  431044            2 YES      3981312 06-JUN-12 02.39.13.000000000 PM                     YES SOLBACHGRP
  431344            2  NO            0 06-JUN-12 02.52.28.000000000 PM                     NO  SOLBACHRP

Neben v$restore_point, v$flashback_database_stat gibt es noch 2 Views, die Auskunft über Flashback Database geben, insbesondere über die Logfiles und möglichen SCNs zum Zurücksetzten. Das sind v$flashback_database_log und v$flashback_database_logfile:

SQL> select * from v$flashback_database_log;

OLDEST_FLASHBACK_SCN OLDEST_FL RETENTION_TARGET FLASHBACK_SIZE ESTIMATED_FLASHBACK_SIZE
-------------------- --------- ---------------- -------------- ------------------------
              393585 04-JUN-12             1440      100106240                 99975168

select * from v$flashback_database_logfile;

NAME                                      LOG# THREAD# SEQUENCE#      BYTES FIRST_CHANGE# FIRST_TIM TYPE
----------------------------------------- ---- ------- --------- ---------- ------------- --------- --------
/fra/ORCL/flashback/o1_mf_7ww54zn4_.flb      1       1         1    8192000        393585 04-JUN-12 NORMAL
/fra/ORCL/flashback/o1_mf_7ww550yt_.flb      2       1         2    8192000        397645 04-JUN-12 NORMAL
...
/fra/ORCL/flashback/o1_mf_7wyblbwy_.flb     22       1        22    3981312        431549 05-JUN-12 NORMAL
/fra/ORCL/flashback/o1_mf_7wyo3o1g_.flb     23       1         1    3981312             0           RESERVED

Gerade bei Testdatenbanken, in denen man Performance testen möchte, kann es empfehlenswert sein, die Flashback Logs vorher anlegen zu lassen, so dass nicht durch das bloße I/O des Create File Befehls die Performance Zahlen verändert werden.

Hierzu können in der Session die Parameter _db_flashback_log_min_size und _db_flashback_log_min_total_space verwendet werden.

SQL> alter system set "_db_flashback_log_min_size"=4g;
SQL> alter system set "_db_flashback_log_min_total_space"=50g;

SQL> alter database flashback on;

Bevor man nun seinen Performancetest startet, sollte über v$flashback_database_log nachgeprüft werden, ob die benötigten Flashback Logs angelegt wurden. Die einzige Problematik liegt nun darin, den richtigen Platz für Total Space zu ermitteln, das funktioniert aber ähnlich wie bei der Berechnung der FRA (s.o.).