Dieses Feature darf nicht mit „Flashback Table (Point in Time)“ verwechselt werden, auch wenn beide Features in der „SQL Language Reference“ von Oracle unter demselben Kommando aufgeführt sind und wenn beide Dinge oft im gleichen Atemzug genannt werden. Das hier gemeinte Flashback Table darf mit der Standard Edition genutzt werden und bezieht sich allein auf das Kommando, mit dem eine gelöschte Tabelle aus dem Recyclebin zurückgeholt wird – wenn er denn auf der Datenbank eingeschaltet ist und die Tabelle auch noch dort ist. Genaugenommen ist diese Art des Flashbacks nichts weiter als ein Rückbenennen der Tabelle. Verfügbar ist der Recyclebin seit Version 9i. Voraussetzung ist, dass der Recyclebin eingeschaltet ist (=Default):
show parameter recyclebin
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
recyclebin string on
conn scott/***@pdb1
drop table t1;
show recyclebin;
ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME
---------------- ------------------------------ ------------ -------------------
T1 BIN$kBPFIf/qF4LgUAoKGDgaJA==$0 TABLE 2019-08-14:14:19:34
flashback table t1 to before drop;
Bei der Wiederherstellung ist unter anderem Folgendes zu beachten:
Flashback Query ist nicht zu verwechseln mit den ähnlich klingenden – und im Übrigen auch auf denselben technischen Grundlagen beruhenden – Features Flashback Transaction oder Flashback Transaction Query, welche die Enterprise Edition erfordern. Mit Flashback Query können versehentlich gelöschte oder geänderte Zeilen einer Tabelle aus dem Undo Tablespace mit einer früheren SCN oder einem Timestamp ausgelesen und so zurückgeholt werden. Flashback Query kam bereits mit der Oracle Version 9i (hier noch in Form von dbms_flashback) und darf in der Standard Edition genutzt werden. Der Parameter UNDO_RETENTION bestimmt, wie lange Daten im UNDO Tablespace möglichst vorzuhalten sind. Allerdings ist dies kein fester Grenzwert sondern Undo Bereiche können auch früher überschrieben werden, wenn nicht ausreichend Platz vorhanden ist. Das Kommando zum Selektieren der Daten mit Flashback Query (SELECT AS OF) lautet:
select * from t1 as of timestamp to_timestamp('14.08.19 14:17:00','dd.mm.yy hh24:mi:ss');
Wie wir hier sehen, wird ein bestimmter Zeitpunkt mitgegeben. Verbunden mit einem insert into können so Daten zurückgeholt und direkt in die Tabelle wieder eingefügt werden.
Dieses Feature ist lt. Ann Sjökvist und Pini Dibask auch mit der Standard Edition nutzbar, Marco Mischke schreibt in seinem Blog, dass die Enterprise Edition lizenziert sein muss. Der Oracle Licensing Guide ist bezüglich der Flashback Features nicht klar interpretierbar. Eine entsprechende Anfrage bei Oracle von der Muniqsoft Consulting GmbH ist aktuell noch nicht beantwortet, so dass Sie hierzu bitte Ihren Account Manager fragen, um sicher zu sein, keine Lizenzverletzung zu begehen.
Diese Art Flashback ist dem Flashback Query sehr ähnlich. Es ist eine Weiterentwicklung von Flashback Query und kam mit Oracle 10g. Der Fokus der Abfrage dient nicht einem vorgegeben Zeitpunkt wie bei Flashback Query sondern den verschiedenen Versionen von einer Zeile innerhalb eines Zeitraumes (VERSIONS BETWEEN). So fragt folgendes Kommando die unterschiedlichen Inhalte der Spalten id und kommentar der Tabelle t1 zur Bedingung id=1 ab:
SELECT versions_xid XID, versions_startscn START_SCN, versions_endscn END_SCN, versions_operation OPERATION, id, kommentar from t1 versions between scn minvalue and maxvalue where id=1;
XID START_SCN END_SCN O ID KOMMENTAR
---------------- ---------- ---------- - ---------- ------------------------------------------------------------
070014005D010000 2086382 U 1 geaendert fuer flashback transaction backout, session 2
09000B00E6010000 2086298 2086382 U 1 geaendert fuer flashback transaction backout, session 1
2086298 1 initial
Wir sehen, wie die Inhalt der kommentar-Spalte zur id=1 waren:
Diese Möglichkeit darf nur mit der Enterprise Edition genutzt werden. Sie ist seit Version 10g verfügbar. Prinzipiell funktioniert diese Methode genauso wie Flashback Query und Flashback Version Query – die Daten werden aus dem Undo Tablespace gelesen. Ein Unterschied: Supplemental Logging muss enabled sein, um vernünftige Ergebnisse zu erhalten. Ein weiterer Unterschied und der entscheidende Vorteil gegenüber Flashback Query und Flashback Version Query ist, dass nicht nur die Änderung einzelner Zeilen ermittelt wird, sondern der gesamte historische Verlauf einer Transaktion nachvollzogen werden kann. Die entsprechenden UNDO-Befehle werden mit erfasst, so dass die gewünschten Transaktionen komfortabel rückgängig gemacht werden können. Diese Möglichkeit ist es sicherlich, welche im Gegensatz zur „einfachen“ Query nur Kunden der Enterprise Edition zugänglich gemacht werden soll.
Abfragt wird die View flashback_transaction_query:
update t2 set id=5 where id=1;
update t2 set id=6 where id=2;
commit;
-- Heraussuchen der XID:
SELECT versions_xid XID, versions_startscn START_SCN, versions_endscn END_SCN, versions_operation OPERATION, id, kommentar from t2 versions between scn minvalue and maxvalue where id in (1,2);
XID START_SCN END_SCN O ID KOMMENTAR
---------------- ---------- ---------- - ---------- ---------------------
05001C00E1010000 2094497 D 1 initial
2094497 1 initial
05001C00E1010000 2094497 D 2 initial
2094497 2 initial
-- Heraussuchen der Undobefehle:
SELECT xid, start_scn , commit_scn, operation, logon_user, undo_sql FROM flashback_transaction_query WHERE xid = hextoraw('05001C00E1010000');
XID START_SCN COMMIT_SCN OPERATION LOGON_USER
---------------- ---------- ---------- -------------------------------- --------------------------------------------------------------------------------------------------------------------------------
UNDO_SQL
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
05001C00E1010000 2094484 2094497 UPDATE SCOTT
update "SCOTT"."T2" set "ID" = '2' where ROWID = 'AAAFtoAALAAAACuAAB';
05001C00E1010000 2094484 2094497 UPDATE SCOTT
update "SCOTT"."T2" set "ID" = '1' where ROWID = 'AAAFtoAALAAAACuAAA';
05001C00E1010000 2094484 2094497 BEGIN SCOTT
SCOTT
Dieses Feature wird auch Flashback Transaction Backout genannt und ist eine Weiterentwicklung von Flashback Transaction. Es ist seit der Version 11g für die Enterprise Edition verfügbar. Vorteil von Flashback Transaction Backout ist, dass nicht nur eine sondern auch weitere, abhängige Transaktionen, die dieselben Tabellen betreffen, zurückgerollt werden können.
Das folgende Beispiel zeigt ein Update auf dieselbe Zeile der Tabelle t1 aus zwei unterschiedlichen Sessions. Die zweite Session ändert zudem noch vor dem Update auf t1 eine weitere Tabelle t2. Anschließend wird per Flashback Transaction Backout auf den Ursprungszeitpunkt zurückgerollt.
Als SYS:
update t1 set datum=sysdate,kommentar='geaendert fuer flashback transaction backout, session 1' where id=1;
commit;
-- in zweiter Session:
update t2 set datum=sysdate,kommentar='geaendert fuer flashback transaction backout, session 2' where fid=1;
update t1 set datum=sysdate,kommentar='geaendert fuer flashback transaction backout, session 2' where id=1;
commit;
select * from t1;
ID DATUM KOMMENTAR
---------- ----------------- ------------------------------------------------------------
1 18.08.19 14:59:04 geaendert fuer flashback transaction backout, session 2
2 18.08.19 14:57:09 initial
3 18.08.19 14:57:09 initial
select * from t2;
ID FID DATUM KOMMENTAR
---------- ---------- ----------------- -------------------------------------------------
1 1 18.08.19 14:59:03 geaendert fuer flashback transaction backout, session 2
2 1 18.08.19 14:59:03 geaendert fuer flashback transaction backout, session 2
3 2 18.08.19 14:57:09 initial
-- XIDs ermitteln (alternativ auch über Logminer möglich):
SELECT versions_xid XID, versions_startscn START_SCN, versions_endscn END_SCN, versions_operation OPERATION, id, kommentar from t1 versions between scn minvalue and maxvalue where id=1;
XID START_SCN END_SCN O ID KOMMENTAR
---------------- ---------- ---------- - ---------- ------------------------------------------------------------
0A00200058010000 2079943 U 1 geaendert fuer flashback transaction backout, session 2
06001700DB010000 2079873 2079943 U 1 geaendert fuer flashback transaction backout, session 1
2079873 1 initial
DECLARE
v_xid SYS.xid_array;
BEGIN
v_xid := sys.xid_array('09000B00E6010000');
DBMS_FLASHBACK.transaction_backout (numtxns => 1, xids => v_xid, options =>DBMS_FLASHBACK.cascade);
END;
/
select * from t1;
ID DATUM KOMMENTAR
---------- ----------------- ------------------------------------------------------------
1 18.08.19 14:57:09 initial
2 18.08.19 14:57:09 initial
3 18.08.19 14:57:09 initial
select * from t2;
ID FID DATUM KOMMENTAR
---------- ---------- ----------------- -------------------------------------------------
1 1 18.08.19 14:57:09 initial
2 1 18.08.19 14:57:09 initial
3 2 18.08.19 14:57:09 initial
Im Beispiel ist erkennbar, dass mit dem Flashback Transaction neben der Transaktion aus der ersten Session auch die gesamte abhängige Transaktion der zweiten Session zurückgerollt wurde. Damit erhielt nicht nur Tabelle t1 ihren Ursprungszustand wieder, auch die Tabelle t2, die ebenfalls in der zweiten Session geändert worden war, wurde zurückgesetzt. Dieses Verhalten muss dem Anwender bei Einsatz von Flashback Transaction Backout bewusst sein.
Flashback Table ist seit Oracle 11g in der Enterprise Edition verfügbar. Wie bereits eingangs beschrieben hat das „Flashback Table“ bis auf die ersten zwei Worte nichts mit dem Befehl „Flashback Table (To-Before-Drop)“ gemein. Flashback Table stellt eine Tabelle aus dem Undo-Tablespace zu einem gewünschten Zeitpunkt in der Vergangenheit wieder her. Es ist komfortabler als Flashback Query (SELECT AS OF), was nur die Selektion von Daten zu einem früheren Zeitpunkt erlaubt. Der Parameter UNDO_RETENTION steuert, dass die Daten die entsprechende Zeit im Undo Tablespace vorgehalten werden, sicherstellen kann er es jedoch nicht. Voraussetzung für Flashback Table ist, dass Row Movement für die Tabelle(n) enabled ist.
delete from t1 where id=3;
commit;
select * from scott.t1;
ID DATUM KOMMENTAR
---------- ----------------- ------------------------------------------------------------
1 18.08.19 17:04:23 initial
2 18.08.19 17:04:23 initial
flashback table t1 to timestamp to_timestamp('18.08.19 17:05','dd.mm.yy hh24:mi:ss');
select * from scott.t1;
ID DATUM KOMMENTAR
---------- ----------------- ------------------------------------------------------------
1 18.08.19 17:04:23 initial
2 18.08.19 17:04:23 initial
3 18.08.19 17:04:23 initial
Ein abschließendes Commit ist hier nicht erforderlich.
Restriktionen von Flashback Table sind unter anderem:
Flashback Data Archive erschien mit Version 11g unter dem Namen Total Recall. Bis einschließlich Version 11.2.0.3 erforderte dieses Feature die Oracle Advanced Compression Option, seit Version 11.2.0.4 kann es in der Basisversion editionsübergreifend ohne Zusatzkosten genutzt werden.
Flashback Data Archive ist eine Verbesserung gegenüber Flashback Table. Geänderte Daten werden nicht mehr allein im Undo sondern in einem/mehreren separaten Tablespace/s in einem/mehreren Archive/n gespeichert. Somit ist garantiert, dass die Wiederherstellung auch zu einem früheren Zeitpunkt, völlig unabhängig von der Vorhaltezeit im UNDO Tablespace, erfolgen kann. Die Aufbewahrungszeit kann somit theoretisch viele Jahre sein. In der Praxis sind jedoch Restriktionen wie hoher Speicherplatzbedarf, Kompatibiliät bei Versionswechseln, Auswirkungen von DDL-Statements und ähnliches zu beachten.
Flashback Data Archive kann sehr vielfältig mit anderen Features (z. B. User Context Tracking) kombiniert werden.
-- no optimize data sonst Advanced Compression Option!:
create flashback archive fda_default tablespace fda_ts retention 1 year no optimize data;
alter flashback archive fda_default set default;
-- !!! nicht vergessen, Fehler gibts sonst erst bei der Wiederherstellung!!!:
alter table t1 enable row movement;
alter table t1 flashback archive;
flashback table t1 to timestamp to_timestamp('18.08.19 17:24','dd.mm.yy hh24:mi:ss');
-- oder nach truncate:
truncate table t1;
flashback table t1 to timestamp to_timestamp('18.08.19 17:24','dd.mm.yy hh24:mi:ss');
*
ERROR at line 1:
ORA-01466: unable to read data - table definition has changed
select * from t1 as of timestamp to_timestamp('18.08.19 17:24','dd.mm.yy hh24:mi:ss');
Flashback Database wurde bereits mit Oracle 10g für die Enterprise Edition eingeführt. Wenn der Flashback Modus in der Datenbank eingeschaltet ist, werden alle Änderungen in der Datenbank nicht nur in den Online/Archived Redo Logfiles protokolliert, sondern parallel dazu auch in Flashback Logs. An Hand dieser kann die gesamte Datenbank (einzelne Tablespaces gehen nicht) lückenlos „zurückgedreht“ werden. Dazu werden die „Before-Images“ der Blöcke aus den Flashback Logs gelesen und mit Hilfe der Archived Redo/Online Logfiles auf den gewünschten Zeitpunkt nach vorn gerollt.
Es ist ein Pendant zum Point-in-Time-Recovery. Sowohl Restore/Recovery als auch Flashback können die gesamte Datenbank auf einen bestimmten Zeitpunkt zurücksetzen. Häufig ist jedoch das Flashback Database schneller, denn er erfolgt auf den vorhandenen Datenbankdateien wohingegen für ein Point-in-Time-Recovery erst ein Restore der Datenfiles erfolgen muss.
Das Limit bezüglich des ältesten Flashback-Zeitpunktes ist der Platz, der für Flashback Logs zur Verfügung steht (Parameter DB_RECOVERY_FILE_DEST_SIZE). Zwar kann über den Parameter DB_FLASHBACK_RETENTION_TARGET die Vorhaltezeit gesetzt werden, wird aber viel geschrieben und der Platz wird eng, dann werden ältere Flashback Logs überschrieben (im Gegensatz zu den Archived Redologs, die niemals überschrieben werden und wo ein Volllaufen der Archive Log Destination zum Stillstand der Datenbank führt).
Mit folgendem Befehl wird Flashback eingeschaltet (bei Multitenant im Root-Container):
alter database flashback on;
-- weiter gehts in der PDB (ab 12.2. ist es möglich, allein die PDB „zu flashbacken“)
conn sys/***@pdb1 as sysdba
select * from scott.t1;
ID DATUM KOMMENTAR
---------- ----------------- ------------------------------------------------------------
1 18.08.19 18:41:07 initial
2 18.08.19 18:41:07 initial
3 18.08.19 18:41:07 initial
drop table scott.t1 cascade constraints;
select * from scott.t1;
*
ERROR at line 1:
ORA-00942: table or view does not exist
select * from v$flashback_database_log;
OLDEST_FLASHBACK_SCN OLDEST_FLASHBACK_ RETENTION_TARGET FLASHBACK_SIZE ESTIMATED_FLASHBACK_SIZE CON_ID
-------------------- ----------------- ---------------- -------------- ------------------------ ----------
2125201 18.08.19 18:42:23 1440 419430400 0 0
alter pluggable database pdb1 close;
flashback pluggable database pdb1 to scn 2125201;
alter pluggable database pdb1 open resetlogs;
select * from scott.t1;
ID DATUM KOMMENTAR
---------- ----------------- ------------------------------------------------------------
1 18.08.19 18:41:07 initial
2 18.08.19 18:41:07 initial
3 18.08.19 18:41:07 initial
Flashback Database kann auch Standby Datenbank genutzt werden. Ab Version 19c werden Flashbacks der primären Datenbank automatisch auf der Standby Datenbank nachgezogen. Ebenso ist ein Flashback Database über ein „open resetlogs“ hinweg möglich.
Guaranteed Restore Points nutzen ebenfalls Flashback Logs, der Flashback Modus muss dazu jedoch nicht eingeschaltet sein. Hier ist die Wiederherstellbarkeit der kompletten Datenbank auf den Zeitpunkt des Guaranteed Restore Points – theoretisch - garantiert. Allerdings – Achtung! – hier gibt es eine Stolperfalle. Wird der Platz in der Fast Recovery Area eng, werden die Archive Redolog Dateien, die bereits gesichert wurden, aus der Fast Recovery Area gelöscht. Dies passiert auch dann, wenn sie für die Herstellung des Guaranteed Restore Points eigentlich noch benötigt würden. In so einem Fall müssten also die Archived Redologs erst wieder restored werden, bevor die Datenbank zurückgesetzt werden kann. Der Restore kann natürlich zeitintensiv sein, so dass auch das Flashback entsprechend dauert. Wäre zudem das Backup der Archived Redolog Dateien unglücklicherweise nicht (mehr) verfügbar, kann auch die Datenbank nicht mehr zurückgesetzt werden! Siehe hierzu auch die MOS-Notes 2396155.1 sowie Enhancement Request/Bug 14546872 und Bug 14395635.
Im Fall von Guaranteed Restore Points wird das Image der Blöcke zum Zeitpunkt des Kommandos „create restore point“ in den Flashback Logs gespeichert. Die weiteren Änderungen der Blöcke werden nicht gespeichert – eine lückenlose Wiederherstellung ist somit nicht möglich. Dies ist aber auch gar nicht die Intention von Guaranteed Restore Points. Es eignet sich vielmehr hervorragend, um ein Fallback für Upgrades zu haben, um Testszenarien immer wieder auf demselben Datenstand aufzusetzen oder auch um Batchjobs wieder zurücksetzen zu können. Es können auch mehrere Restore Points gesetzt werden.
conn sys/***@pdb1 as sysdba
select * from scott.t1;
ID DATUM KOMMENTAR
---------- ----------------- ------------------------------------------------------------
1 18.08.19 18:41:07 initial
2 18.08.19 18:41:07 initial
3 18.08.19 18:41:07 initial
create restore point restore_pdb1_20190818 guarantee flashback database;
drop table scott.t1 cascade constraints;
select * from scott.t1;
*
ERROR at line 1:
ORA-00942: table or view does not exist
alter pluggable database pdb1 close;
flashback pluggable database pdb1 to restore point restore_pdb1_20190818;
alter pluggable database pdb1 open resetlogs;
select * from scott.t1;
ID DATUM KOMMENTAR
---------- ----------------- ------------------------------------------------------------
1 18.08.19 18:41:07 initial
2 18.08.19 18:41:07 initial
3 18.08.19 18:41:07 initial
Der Guaranteed Restore Point kann ebenfalls auf Standby Datenbanken manuell gesetzt werden. Ab 19c werden Restore Points, die auf der primären Datenbank gesetzt sind, auch auf die Standby Datenbanken übertragen. Wird die primäre Datenbank „geflashbackt“, erfolgt diese Aktion automatisiert auch auf der Standby Datenbank.
Alle Wiederherstellungsverfahren unterliegen Restriktionen. Am stabilsten einsetzbar ist hier tatsächlich „Flashback Database“, was allerdings dann nicht zum Einsatz kommen kann, wenn nur einige Tabellen bzw. Daten betroffen sind.
Jedoch insbesondere der Flashback einzelner Objekte aus Undo Tablespace oder dem Recyclebin hat viele, viele Beschränkungen. Sobald von einer „normalen“ Tabelle weggegangen wird, wird es komplex. Constraints oder Indices können vorhanden sein und müssen wiederhergestellt werden. Das Vorhandensein von Triggern, die ihrerseits wiederum Daten manipulieren können, muss berücksichtigt werden. Die Retention Time von LOBs ist separat zu konfigurieren. Bestimmte Datentype können außerhalb von „Flashback Database“ nicht „geflashbackt“ werden. Oft ist ein Flashback nach DDL auf dem Objekt nicht mehr möglich. Oder das DDL ist nicht möglich oder nur sehr mühsam über Zwischenschritte zu erreichen, weil eine Tabelle zum Beispiel einem Flashback Data Archive zugeordnet ist. Fine Grained Access Policies kommen ins Spiel. Mehrere Transaktionen ändern unterschiedliche und auch dieselben Tabellen und beeinflussen sich somit gegenseitig. Niedrigere Oracle Versionen unterliegen oft mehr Limitierungen. All dies muss überprüft werden, wenn ein bestimmtes Verfahren ernsthaft regelmäßig zum Einsatz kommen soll.
Alle Restriktionen an dieser Stelle zu erfassen, sprengt den Rahmen dieses Tipps. Sie müssen dann genauestens untersucht und getestet werden, wenn eine bestimmte Flashbackmethode regelmäßig eingesetzt werden soll.
Unter dem Begriff Flashback verbergen sich im Oracle Kontext viele Möglichkeiten, Daten wiederherzustellen. Manche Möglichkeiten sind „out-of-the-box“ vorhanden, manche müssen explizit VOR der Datenänderung konfiguriert werden, um bei Datenverlust mit der entsprechenden Methode die Daten wiederherstellen zu können. Es lohnt sich auf jeden Fall, die Möglichkeiten zu kennen und einige von ihnen auch prophylaktisch zu implementieren, um im Fehlerfall schnell Daten wiederherstellen zu können.
Für Wahl der Wiederherstellungsverfahren sind folgende Fragen entscheidend:
Hier sind noch einmal die betrachteten Flashback-Verfahren in einer Übersicht zu sehen:
Es scheint, dass sich bezüglich Flashback nach 11g nichts mehr getan hat. Aber so ist es nicht. Mit 12c treten neue Begriffe in den Vordergrund, die aber viel mit Zeileninhalten zu bestimmten Zeiten zu tun haben. Hier geht es nicht mehr um die Wiederherstellung von Daten aus der Vergangenheit, weil sie falsch geändert wurden. Nein, hier geht es bewusst um Versionierung von Daten zu bestimmten Zeitpunkten. Das Stichwort hierzu ist: Information Lifecycle Management (ILM) und insbesondere Temporal Validity Flashback Queries. Aufbauen tut ILM auf Flashback Data Archives. Das zugehörige Package: DBMS_FLASHBACK_ARCHIVE. Es wird also nicht langweilig.
Inderpal S. Johal, „ORACLE FLASHBACK – 9i To 10g”: http://www.datasoftech.com/library/NJOUG_flashback.pdf
Ann Sjökvist, “Flashback on Oracle SE“: https://www.sejustloveit.com/oracle-se-dba/flashback-on-oracle-se/
Pint Dibask, “Ensuring Data Protection Using Oracle Flashback Features - Part 5”: http://oracledbpro.blogspot.com/2016/05/ensuring-data-protection-using-oracle_22.html
Marco Mischke, “Flashback – Recover without Recovery”: https://dbamarco.wordpress.com/2015/06/15/flashback-recover-without-recovery/
Ulrike Schwinn, „Oracle SQL für mehr Funktionalität und Performance“: https://www.doag.org/formes/pubfiles/8009817/2016-NN-Ulrike_Schwinn-Oracle_SQL_fuer_mehr_Funktionalitaet_und_Performance_-Praesentation.pdf
In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den
Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.
