|
Flashback in Oracle
Flashback ist schon lange ein Feature, das die Oracle Datenbank in den verschiedensten Ausprägungen unterstützt.
Flashback in Oracle Datenbank bedeutet ganz generell, Daten eines früheren Zeitpunkts zur Verfügung zu stellen.
Schon in Oracle 9i wurde begonnen diese Anforderung durch das Flashback Query Konzept in der Datenbank zu implementieren.
Damit ist es beispielsweise möglich, Daten zu einem früheren Zeitpunkt auf Session- bzw. Statement- Ebene zur Verfügung zu stellen.
Aber auch in den folgenden Datenbank Releases wurden weitere features hinzugefügt.
In Oracle Database 10g beispieslweise wurde diese Technologie um neue Konzepte erweitert, die es erlauben, Flashback von Tabellen bis auf Datenbankebene zu nutzen.
In 11g sind Erweiterungen im Bereich Transaktionen (siehe Flashback Transaction) und das Monitoren von Daten über ihren gesamten Lebenszyklus
(siehe Flashback Data Archive) implementiert worden. In Oracle12c wird Valid Time Supports für Tabellenzeilen - auch temporal Validity - eingeführt.
Einige Beispiele für die Nutzung der Flashback Technologien sind:
- Abfragen um Informationen aus der Vergangenheit zu selektieren
- Rollback von Transaktionen
- Wiederherstellen von gelöschten Tabellen
- Zurücksetzen der gesamten Datenbank ohne Point-in-Time Recovery
- Tabellenzeile mit einem Gültigkeitszeitraum versehen
Alle Flashback Features stehen automatisch ohne zusätzliche Installation in allen On-Premises Installationen und allen Cloud Editionen zur
Verfügung - egal auch ob eine Multitenant oder RAC Architektur in Verwednung ist. Die Nutzung speziell der Flashback Query Technologie ist sogar in Oracle Werkzeugen wie APEX als Standard implementiert und ohne Kenntnis der
entsprechenden Syntax verwendbar.
Folgende Abschnitte geben einen kurzen Überblick und eine kurze Beschreibung über einzelne ausgewählte Techniken.
Flashback Query
Hiermit wird die Abfrage von Daten zu einem früheren Zeitpunkt ermöglicht. Dabei kann immer nur eine einzige Version der Daten pro Statement selektiert werden.
Eine fehlerhaften Dateneingabe, die schon mit COMMIT festgeschrieben ist, kann auf diese Weise rückgängig gemacht werden. Ein anderer Anwendungsfall wäre,
einen Datenvergleich zu verschiedenen Zeitpunkten zu ermöglichen.
Implementiert ist diese Technik über die AS OF Klausel im SELECT Statement oder über das Package DBMS_FLASHBACK für eine gesamte Session. Mit DBMS_FLASHBACK.ENABLE_AT_TIME
oder DBMS_FLASHBACK.ENABLE_AT_SYSTEM_CHANGE_NUMBER kann Flashback Query auf alle Statements einer Session ausgeweitet werden. Mit der Prozedur DBMS_FLASHBACK.DISABLE
wird dieser Zustand für die Session beendet.
Einzige Voraussetzung ist die Nutzung von UNDO Management, d.h. das Setzen von UNDO_MANAGEMENT=AUTO.
Um Flashback Query Feature zu nutzen, ist es generell wichtig, Zugriff auf ältere (schon mit Commit abgeschlossene) Daten zu haben. Daher verwendet Oracle die sogenannte Undo Retention - das ist die Dauer, die die Undo Daten nach Abschluss einer Transaktion gehalten werden.
Der Parameter UNDO_RETENTION, falls gesetzt, fungiert dabei als untere Grenze, damit die Undo Daten mindestens so lange vorgehalten werden,
wie der Parameter in Sekunden angibt.
Hinweis: Seit 10g gibt es ein automatisches Undo Tuning für die Bestimmung der Undo Retention. Die Datenbank (MMON) sammelt Statistiken und tunt die Undo Retention Periode basierend auf diesen Statistiken. Für AUTOEXTEND Undo Tablespaces bedeutet dies, dass das System
Undo für mindestens den Zeitraum von UNDO_RETENTION beibehalten wird, für "fixed-size" Tablespaces hingegen wird die maximale UNDO Periode berechnet, und der UNDO_RETENTION Parameter ignoriert. Mehr Informationen dazu finden Sie auch in der Note 461480.1.
Die folgende Query listet die getunte Undo Retention:
SQL> SELECT TO_CHAR(BEGIN_TIME, 'MM/DD/YYYY HH24:MI:SS') BEGIN_TIME, TUNED_UNDORETENTION
FROM V$UNDOSTAT
BEGIN_TIME TUNED_UNDORETENTION
------------------- -------------------
09/27/2019 12:22:01 900
09/27/2019 12:12:01 900
09/27/2019 12:02:01 900
09/27/2019 11:52:01 900
09/27/2019 11:42:01 900
09/27/2019 11:32:01 900
...
Falls der UNDO Platz nicht ausreichend vorhanden ist, werden die DML Operationen trotzdem durchgeführt, und es kann beim Flashback Query zum "Ora-1555 "snapshot too old" Fehler kommen. Gibt man zusätzlich beim Anlegen des UNDO Tablespaces RETENTION GUARANTEE mit, wird im Gegensatz zum Default Verhalten garantiert, dass
zugunsten der Vorhaltezeit (UNDO_RETENTION) der Platz reserviert bleibt. DML-Operationen, die den UNDO-Platz benötigen, könnten dann allerdings aus Platzmangel fehlschlagen.
SQL>SELECT * FROM scott.dept;
DEPTNO DNAME LOC
---------- -------------- -------------
10 ACCOUNTING FRANKFURT
20 RESEARCH DALLAS
30 SALES CHICAGO
40 OPERATIONS BOSTON
50 SALES STUTTGART
Mit folgender Abfrage kann man sich nun einen "älteren" Stand der Daten ansehen.
SQL> SELECT * FROM scott.dept AS OF TIMESTAMP to_timestamp('27-09-2019 10:15','dd-mm-yyyy hh24:mi:ss');
DEPTNO DNAME LOC
---------- -------------- -------------
10 ACCOUNTING NEW YORK
20 RESEARCH DALLAS
30 SALES CHICAGO
40 OPERATIONS BOSTON
Folgendes Beispiel zeigt die out-of-the-box Implementierung von Flashback Query in APEX. Der Anwender kann im Menü "Actions" den Menüpunkt "Data"
und danach "Flashback" auswählen. Danach können die Daten zu einem älteren Zeitpunkt (Angabe in Minuten) abgefragt werden.
Flashback Table
Möchte man alle versehentlich abgesetzten DML-Operationen einer Tabelle "auf einen Schlag" zurücksetzen, eignet sich die Flashback Table Technologie. Flashback Table ermöglicht über ein einziges Kommando das Zurücksetzen einer Tabelle oder mehrere Tabellen auf einen bestimmten Zeitpunkt, der durch eine SCN oder eine bestimmte Zeitangabe (TIMESTAMP) definiert ist. Wichtig zu wissen ist, dass keine DDL Operationen in diesem Zeitraum erfolgt sein dürfen und ROW MOVEMENT für die Tabelle eingeschaltet sein muss.
SQL>ALTER TABLE scott.dept ENABLE ROW MOVEMENT;
Table altered.
SQL>FLASHBACK TABLE scott.dept TO TIMESTAMP to_timestamp('27-SEP-2019 12:00','dd-mon-yyyy hh24:mi');
Flashback succeeded.
SQL> SELECT * FROM scott.dept;
DEPTNO DNAME LOC
---------- -------------- -------------
10 ACCOUNTING NEW YORK
20 RESEARCH DALLAS
30 SALES CHICAGO
40 OPERATIONS BOSTON
Flashback Drop
Hiermit wird das DROP TABLE Kommando rückgängig gemacht. Die Nutzung erfolgt in Verbindung mit dem Recyclebin. In 11g ist der Parameter RECYCLEBIN per Default auf ON gesetzt. Um dieses Feature zu nutzen, sollte diese Einstellung beibehalten werden. Bei einem DROP TABLE Kommando werden automatisch die Tabellen und zugehörige Objekte wie Indizes, Constraints (ausser referentielle Integrität) und nested tables im sogenannten Recyclebin zur Verfügung gestellt. Dies führt keineswegs zu Performance-Einbussen, da ein einfaches Umbenennen der zugehörigen Objekte und kein explizites Kopieren in einen neuen Bereich erfolgt. Somit ist auch klar, dass im Gegensatz zu den oben genannten Flashback Funktionalitäten Flashback Drop nicht von der UNDO Retention Zeit abhängig ist, sondern vom verfügbaren Platz im Tablespace. Die Extents der gelöschten Tabelle werden nur als gelöscht markiert und erst dann überschrieben, wenn der Platz im Tablespace dies erfordert.
SQL> show parameter recyclebin NAME TYPE VALUE ------------------------------------ ----------- --------------------- recyclebin string on
Nehmen wir an es wurde aus Versehen die Tabelle EMP gelöscht. Diese kann dann wie folgt wieder hergestellt werden.
SQL> drop table emp;
Table EMP dropped.
SQL> SELECT object_name, original_name, type, droptime
FROM user_recyclebin order by droptime desc
OBJECT_NAME ORIGINAL_NAME TYPE DROPTIME
------------------------------ -------------------------- ---------------------- --------------------
BIN$k4r0uxKwyu3gUwsAAApXeQ==$0 EMP TABLE 2019-09-27:14:46:49
BIN$kab+svkOFwngUwsAAArVdw==$0 VG2500_BLD TABLE 2019-09-03:13:25:13
SYS_LOB0000074153C00022$$ SYS_LOB0000074153C00022$$ LOB 2019-09-03:13:25:13
SYS_LOB0000074153C00023$$ SYS_LOB0000074153C00023$$ LOB 2019-09-03:13:25:13
SYS_IL0000074153C00013$$ SYS_IL0000074153C00013$$ LOB INDEX 2019-09-03:13:25:13
SQL> FLASHBACK TABLE "BIN$k4r0uxKwyu3gUwsAAApXeQ==$0" TO BEFORE DROP RENAME TO emp;
Flashback complete.
SQL> SELECT * FROM emp;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- ----------
7369 SMITH CLERK 7902 17.12.80 800 20
7499 ALLEN SALESMAN 7698 20.02.81 1600 300 30
7521 WARD SALESMAN 7698 22.02.81 1250 500 30
7566 JONES MANAGER 7839 02.04.81 2975 20
7654 MARTIN SALESMAN 7698 28.09.81 1250 1400 30
7698 BLAKE MANAGER 7839 01.05.81 2850 30
7782 CLARK MANAGER 7839 09.06.81 2450 10
7788 SCOTT ANALYST 7566 19.04.87 3000 20
7839 KING PRESIDENT 17.11.81 5000 10
7844 TURNER SALESMAN 7698 08.09.81 1500 0 30
7876 ADAMS CLERK 7788 23.05.87 1100 20
7900 JAMES CLERK 7698 03.12.81 950 30
7902 FORD ANALYST 7566 03.12.81 3000 20
7934 MILLER CLERK 7782 23.01.82 1300 10
Hinweis: Möchte man die Objekte vollständig aus dem Recyclebin löschen, kann man dies mit PURGE RECYCLEBIN oder mit PURGE DBA_RECYCLEBIN für alle Objekte manuell erreichen.
Flashback Drop bzw. Flashback Table sind übrigens auch über den Enterprise Manager verwendbar. Unter "High Availability => Perform Backup" finden sich
die Operationstypen "Flashback Existing Tables" für die Flashback Table und "Flashback Dropped Tables" für die Flashback Drop Operationen.
Temporal Validity
Kurz erklärt kann man mit Temporal Validity eine Tabellenzeile mit einem Gältigkeitszeitraum versehen. Bei Abfragen ist es dann möglich dann einen Zeitpunkt mitzugeben. Die Abfrage liefert dann nur die Zeilen zuräck, die zu jenem Zeitpunkt gältig waren. Folgendes Beispiel beschreibt die Funktionalität. Die Tabelle muss zuerst mit einer invisible (unsichtbaren) Spalte versehen werden.
SQL> alter table emp ADD PERIOD FOR valid_time; Table EMP altered. SQL> select column_name, data_type, hidden_column from user_tab_cols where table_name='EMP'; COLUMN_NAME DATA_TYPE HID ------------------------------------------- --------------------------------------------------------------- --- EMPNO NUMBER NO ENAME VARCHAR2 NO JOB VARCHAR2 NO MGR NUMBER NO HIREDATE DATE NO SAL NUMBER NO COMM NUMBER NO DEPTNO NUMBER NO VALID_TIME_START TIMESTAMP(6) WITH TIME ZONE YES VALID_TIME_END TIMESTAMP(6) WITH TIME ZONE YES VALID_TIME NUMBER YES 11 rows selected.
Nun kann fär jede Tabellenzeile die Gältigkeit gesetzt werden. Das folgende Update-Kommando macht alle Zeilen mit DEPTNO = 20 nur im Dezember 2019 gältig.
SQL> update emp set
VALID_TIME_START = to_timestamp('2019-12-01','YYYY-MM-DD'),
VALID_TIME_END = to_timestamp('2019-12-31','YYYY-MM-DD')
where deptno = 20;
5 rows updated.
Mit einem Aufruf von DBMS_FLASHBACK_ARCHIVE.ENABLE_AT_VALID_TIME kann nun der "Abfragezeitpunkt" gesetzt werden. Daraufhin werden die entsprechenden Zeilen mit DEPTNO = 20 fehlen ...
begin
dbms_flashback_archive.ENABLE_AT_VALID_TIME (
level => 'ASOF',
query_time => to_timestamp('2019-01-01','YYYY-MM-DD') );
end;
/
PL/SQL procedure successfully completed.
Wie man erkennen kann, fehlen bei der folgenden Abfrage die Zeilen mit der DEPTNO 20.
SQL> select deptno, count(empno) anzahl from emp group by deptno;
DEPTNO ANZAHL
---------- ----------
30 6
10 3
Der "Abfragezeitstempel" kann natärlich auch wieder abgeschaltet werden.
SQL> begin
dbms_flashback_archive.ENABLE_AT_VALID_TIME (
level => 'ALL' );
end;
/
SQL> select deptno, count(empno) anzahl from emp group by deptno;
DEPTNO ANZAHL
---------- ----------
30 6
10 3
20 5
Anstatt eine Tabellenzeile zu löschen oder zu verändern, kann man nun die Gältigkeit in den Spalten VALID_TIME_START und VALID_TIME_END setzen. Allerdings nutzt die Datenbank (noch) nicht das Management eines Temporal Primary Key: Sie mässen also beim Erstellen des Primary Key Constraints die Tatsache beräcksichtigen, dass es mehrere Zeilen mit der gleichen ID, aber unterschiedlicher Gältigkeit geben kann. Zusammengesetzte Primärschlässel können hier helfen. Weitere Informationen dazu finden sich im Handbuch VLDB and Partitioning Guide
Flashback Database
Muss die gesamte Datenbank zurückgesetzt werden, da Operationen wie DROP USER, TRUNCATE usw. versehentlich durchgeführt wurden,
kann die Flashback Database Technik zum Einsatz kommen. Das Konzept des Flashback Database, eine Art "Rewind Button" der Datenbank, führt ähnlich wie das Point-In-Time-Recovery, die Datenbank in einen konsistenten
Zustand in der Vergangenheit zurück. Diese Operation ist sehr schnell, da kein Restore eines Backups wie beim normalen Recovery erforderlich ist.
Notwendig für die Nutzung ist der Archivelog Mode und zusätzlich auch ein spezieller Flashbacklog Mode.
Hinweis: Wichtig zu wissen ist, dass man auch ohne Verwednung von Flashback Logging die Flashback Database Technologie verwenden kann. Allerdings ist dazu
die Nutzung von Guaranteed Restore Points erforderlich.
Mehr dazu findet sich in einem unserer älteren Beiträgen unter Flashback Database
Flashback Data Archive
Diese Technologie steht ab 11g zur Verfügung und liefert einen Mechanismus zum lückenlosen Aufbewahren von Datensätzen über eine festgelegte Frist. Diese Frist kann im Unterschied zum Flashback Query beliebig lang sein zum Beispiel auch eine Zeitspanne über Jahre umfassen - im Extremfall über den gesamten Lebenszyklus. Sinnvoll ist dieses Feature, um Compliance zu gewährleisten oder Auditings durchzuführen. Wer mehr darüber erfahren möchte, kann im Tipp Flashback Data Archives: Das perfekte Gedächtnis der Datenbank die notwendigen Details erfahren.
Konfiguration und Implementierung
Wichtig zu wissen ist, dass die einzelnen Technologien unterschiedlich implementiert sind und somit ein unterschiedliches Setup benötigen.
So werden je nach Feature, Undo Informationen, Archive Log, Supplemental Log, Flashback Log oder Recyclebin Informationen benötigt.
Folgende Tabelle fasst die notwendigen Konfigurationsparameter pro Technologie zusammen:
| Technologie | Konfiguration |
| Flashback Query | automatisches UNDO Management |
| Flashback Versions Query | automatisches UNDO Management |
| Flashback Query | automatisches UNDO Management |
| Flashback Transaction Query | automatisches UNDO Management und Supplemental Logging |
| Flashback Table | automatisches UNDO Management und Table Row Movement |
| Flashback Drop | Initialisierungsparameter RECYCLEBIN |
| Flashback Transaction | Archive Log und Supplemental Logging |
| Flashback Database | Archive Log und Flashback Log Mode |
| Flashback Data Archive | Flashback Archive |
| Temporal Validity | Invisible Columns |
Lizenzierung
Flashback Table, Flashback Database, Flashback Transaction und Flashback Transaction Query stehen in der Enterprise Edition zur Verfügung.
Ursprünglich waren die Archive als eigenständige Option zur Enterprise Edition der Oracle Database 11g unter dem Namen Total Recall
eingeführt wurden - was übersetzt so viel heißt wie 'das perfekte Gedächtnis'. Seit 2012 steht das Basic Flashback Data Archive Offering in allen Editionen zur Verfügung.
Möchte man allerdings zusätzlich eine Speicheroptimierung verwenden ist die Advanced Compression Option nötig.
Flashback Query bzw. Flashback Versions Query und Flashback Drop hingegen stehen in allen Editionen ohne zusätzliche Lizenzierung zur Verfügung.
Einen guten Überblick erhält man wie immer im Database Licensing Information User Manual.
Zurück zur Community-Seite