Flashback

Flashback Database

Wenn v_$database.flashback_on auf yes steht, kann man die Datenbank auf einen vorigen Zeitpunkt zurücksetzen. Beispiel:

SQL> shutdown immediate;
SQL> startup mount;
SQL> FLASHBACK DATABASE TO TIMESTAMP TO_TIMESTAMP('2015-06-29 16:00:00', 'YYYY-MM-DD HH24:MI:SS');
SQL> alter database open resetlogs;

Dazu benutzt Oracle das Backup. D.h. es funktioniert nur, wenn man für den gewünschten Zeitpunkt ein Backup mitsamt Redo-Logs hat.

Wenn man feststellt, dass man noch weiter zurückgehen muss, dann geht das auch. Was aber nicht geht, ist wieder "nach vorne" zu gehen. Das geht evtl. noch mit irgendwelchen Tricks wie Controlfile manipulieren damit er glaubt man hätte das open resetlogs nicht gemacht, aber wie man dann die archivelogs nochmal laufen lassen könnte weiß ich nicht.

Alternativ kann man auch einen garantierten Restore Point erzeugen:

SQL> CREATE RESTORE POINT tmpue GUARANTEE FLASHBACK DATABASE;

Oracle erzeugt dann eine *.flb-Datei. Mit 

SQL> FLASHBACK DATABASE TO RESTORE POINT tmpue_guarantee

kann man die DB auf diesen Restore Point zurücksetzen. Dazu benötigt man kein Backup, wohl aber die Redo-Logs. Dieses Kommando ist einiges schneller als das obige.

Flashback Database Forward

Mit Flashback Database kann man nur zurück, nicht "vorwärts" flashen. Beispiel: Man legt monatlich einen Restore Point an. Hat man die DB z.B. auf eine Restore Point im März zurückgesetzt, und versucht sie auf April zu setzen bekommt man die Meldung:

SQL> FLASHBACK DATABASE TO RESTORE POINT rp_april
*
ERROR at line 1:
ORA-38754: FLASHBACK DATABASE not started; required redo log is not available
ORA-38762: redo logs needed for SCN 13757073257149 to SCN 13757073394001
ORA-38761: redo log sequence 4 in thread 1, incarnation 23 could not be
accessed

Zurücksetzen auf Februar ist dahingegen kein Problem.

Flashback Table 

funktionoiert ganz anders, nämlich über den Undo-Tablespace. Darum geht's im Folgenden:
 
Nur maximal 15 Minuten …

… kann man bei 10g  in die Vergangenheit gucken (bei 9iR2 anscheinend bedeutend länger). Es sei denn, man setzt undo_retention beispielsweise auf 7 Tage. Der Undo-Tablespace sollte dann auto_extend on haben (was er normalerweise hat).

ALTER SYSTEM SET UNDO_RETENTION = 604800

Daten zurückholen (also Vorsicht!!!):

create table emp as select * from t;

delete from t;

commit;

select * from t as of timestamp(systimestamp - interval '10' minute);

Das funktioniert immer – auch bei 9i R2

Folgendes funktioniert nur, wenn man "Row Movement" aktiviert hat (im Enterprise Manager unter Admin – Schema Tabellen – Tabelle anklicken – Optionen – Zeilenverschiebung aktivieren):

flashback table t to timestamp(systimestamp - interval '1' minute);

Gelöschte Tabelle zurückholen:

drop table t;

FLASHBACK TABLE t TO BEFORE DROP;

Das funktioniert immer.

Gucken wie sich die Daten in einem bestimmten Zeitraum verändert haben:

SELECT scott.emp.*, VERSIONS_XID, VERSIONS_STARTTIME, VERSIONS_ENDTIME, VERSIONS_OPERATION

FROM scott.emp

  VERSIONS BETWEEN TIMESTAMP

    SYSTIMESTAMP - INTERVAL '17' MINUTE AND

    SYSTIMESTAMP - INTERVAL '1' SECOND

where empno='7654'

;

Es erscheinen mehrere Datensätze, User und weitere Infos kann man (als SYS) mit

SELECT e.*, e.VERSIONS_XID, q.*

FROM

(scott.emp

  VERSIONS BETWEEN TIMESTAMP

    SYSTIMESTAMP - INTERVAL '15' MINUTE AND

    SYSTIMESTAMP - INTERVAL '1' SECOND

) e,

FLASHBACK_TRANSACTION_QUERY q

where e.empno='7654' and e.VERSIONS_XID = q.xid

order by q.commit_timestamp asc, q.undo_change# desc

;

herausfinden.