Die Zeitmaschine – Oracle Database 10g Flashback

Die Zeitmaschine – Oracle Database 10g Flashback

Die Zeitmaschine – Oracle Database 10g Flashback
Ulrike Schwinn
Oracle Deutschland GmbH
Business Unit Datenbank
München
Schlüsselwörter
flashback database, flash recovery area, flashback log, flashback table, flashback drop, recycle
bin, flashback versions query, flashback transaction query
Zusammenfassung
Flashback in Oracle bedeutet Daten zu einem früheren Zeitpunkt zur Verfügung zu stellen oder
die Zeit zurückzuspulen (engl.: rewind). Schon in Oracle9i wurde begonnen diese Anforderung
durch das flashback query -Konzept in der Datenbank zu implementieren. Damit ist es möglich,
Daten zu einem früheren Zeitpunkt auf Session- bzw. Statement- Ebene zur Verfügung zu
stellen. In Oracle Database 10g wurde diese Technologie um neue Konzepte erweitert, die es
erlauben, Flashback bis auf Datenbankebene zu nutzen. In diesem Beitrag werden die
verschiedenen Arten des Flashbacks wie flashback database, flashback table, flashback drop
und die Auditing- Erweiterungen durch flashback versions und flashback transaction query
erläutert und an Beispielen demonstriert.
Einleitung
Viele Applikationsausfälle beruhen auf logischen Korruptionen, die zum Beispiel durch
Anwenderfehler oder fehlerhafte Batchjobs ausgelöst werden. Löschen von Tabellen, Einfügen,
Löschen oder Ändern von Datensätzen, versehentlich gestartete Batchjobs sind häufig die
Ursache dafür. In der Regel sind diese Fehler schwieriger und meist nur mit langwierigen und
komplexen Prozeduren zu beseitigen. Manuelle Eingabe der Daten, Einspielen des letzten Cold
Backups, Datenbank- oder Tablespace-Point-In-Time- Recovery sind die traditionellen
Methoden in früheren Datenbankversionen, um solchen Fehlern zu begegnen.
Oracle Database 10g hingegen liefert neue Konzepte und Kommandos, um schnell und einfach
die Datenbank auf verschiedenen Ebenen in einen konsistenten Zustand der Vergangenheit
zurückzuversetzen.
Das flashback database- Konzept
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. Dazu wird ein einziges FLASHBACK DATABASE– Kommando, das im
RMAN oder in SQL*Plus ausgeführt wird, benötigt. Wie kann dies funktionieren?
Flashback database beruht auf einem eigens dafür konfigurierten Bereich der Datenbank, der
sogenannten flash recovery area. In speziellen flashback log-Dateien werden regelmäßig die
Kopien der geänderten Blöcke geschrieben. Die flash recovery area wird durch die neuen
Initialisierungsparameter DB_RECOVERY_FILE_DEST und DB_RECOVERY_DEST_SIZE
festgelegt. Falls kein ARCHIVE_LOG_DEST_n Parameter eingestellt ist, enthält dieser die
flashback log-Dateien und zusätzlich die archivierten log Dateien und RMAN Backups.
Abb. 1: Bereiche der flash recovery area
Um Flashback nutzen zu können, sind folgende Einstellungen notwendig:
1) Bereitstellen des Recovery Bereichs:
SQL> SHOW PARAMETER db_recovery
NAME
TYPE
VALUE
---------------------------- ----------- ----------db_recovery_file_dest
string
/space/app/oracle/
flash_recovery_area
db_recovery_file_dest_size big integer 2G
2) Flashback und ARCHIVELOG- Datenbank-Einstellungen:
SQL> show parameter flash
NAME
TYPE
VALUE
------------------------------------ ----------- --------------db_flashback_retention_target
integer
1440
SQL> SELECT flashback_on, log_mode FROM v$database;
FLA LOG_MODE
--- ---------YES ARCHIVELOG
Falls die flashback database- Option noch nicht eingestellt worden ist, kann dies durch das
Kommando ALTER DATABASE FLASHBACK ON im MOUNT- Stadium der Datenbank
durchgeführt werden. Die Datenbank muss zusätzlich im ARCHIVELOG-Mode sein, da
archivierte Log- Dateien während des Flashbacks genutzt werden.
Die Frage, wie weit mit existierenden flashback logs zurückgegangen 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 (siehe Abb 2)
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 20.10.2003 19:14
449691648
Abb. 2: Einstellen der flash recovery area im Enterprise Manager
Im Fehlerfall kann ein Flashback der Datenbank durch folgende Kommandos im MOUNTStadium der Datenbank durchgeführt werden:
FLASHBACK DATABASE TO SCN
oder
FLASHBACK DATABASE TO TIMESTAMP <timestamp>
Im Gegensatz zur Ausführung in RMAN muss bei der Ausführung in SQL*Plus sichergestellt
sein, dass alle benötigten Dateien auf der Festplatte zur Verfügung stehen.
Danach wird die Datenbank mit der Option OPEN RESETLOGS geöffnet.
Probleme ausgelöst durch gelöschte Tabellen, User und Tablespaces, versehentlich
durchgeführte TRUNCATE Kommandos usw. 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
RESETLOGS geöffnet werden muss.
In folgendem Beispiel wird das versehentliche Löschen eine Users rückgängig gemacht.
1) Löschen des Users:
SQL > DROP USER hr CASCADE;
User dropped
2) Durch das FLASHBACK DATABASE-Kommando wird der Zustand vor dem Löschen des
Users wiederhergestellt:
SQL>STARTUP MOUNT
SQL>FLASHBACK DATABASE TO SCN 11359846;
Flashback complete.
SQL> ALTER DATABASE OPEN RESETLOGS;
Database altered.
SQL> SELECT username FROM dba_users;
USERNAME
-----------------------------FLASHBACK
OE
ULRIKE
TEST
HR
SH
MDDATA
IX
DIP
PM
BI
....
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.
Das flashback query-Konzept
Der flashback database- Konzept ist sicherlich für versehentlich durchgeführte DMLKommandos überdimensioniert; insbesondere weil flashback database im MOUNT- Stadium
durchgeführt wird und die gesamte Datenbank zurücksetzt.
Die Technik des flashback table hingegen ermöglicht es, eine Tabelle oder mehrere Tabellen zu
einem bestimmten Zeitpunkt, der durch eine SCN oder einen Zeitpunkt (TIMESTAMP) definiert
ist, zurückzusetzen.
Folgendes Kommando zeigt die Verwendung:
SQL> FLASHBACK TABLE employees, departments TO TIMESTAMP
2> TO_TIMESTAMP('21-oct-2003, 18:50:28','dd-mon-yyyy,
3> hh24:mi:ss');
Flashback complete.
Constraints und Indizes werden während der Operation berücksichtigt. Trigger sind
standardmäßig ausgeschaltet, können aber mit der zusätzlichen Option „ENABLE TRIGGERS“
während des Flashbacks aktiviert bleiben.
Nur DML-Operationen können auf diese Weise zurückgesetzt werden. DDL-Kommandos wie
ALTER TABLE ...DROP COLUMN, ALTER TABLE...DROP PARTITION, ALTER TABLE
MOVE, TRUNCATE TABLE usw. können damit nicht zurückgeführt werden.
Der Versuch, Tabellen zu einem Zeitpunkt vor einem DDL Kommando zurückzusetzen, führt zu
folgendem Verhalten:
SQL>FLASHBACK TABLE departments TO TIMESTAMP
2>TO_TIMESTAMP('21-oct-2003 18:57:55','dd-mon-yyyy hh24:mi:ss')
*
ERROR at line 1:
ORA-01466: unable to read data - table definition has changed
Da beim FLASHBACK TABLE- Operationen an Zeilen durchgeführt werden und unter
Umständen ROWIDs verändert werden müssen, sollte zuvor row movement eingestellt sein.
ALTER TABLE <table_name> ENABLE ROW MOVEMENT;
Darüber hinaus muss der Nutzer von flashback table entweder das Systemprivileg
FLASHBACK ANY TABLE oder aber die Objektprivilegien FLASHBACK, INSERT,
UPDATE und DELETE auf den Tabellen besitzen.
Im Unterschied zu der vorher erläuterten flash recovery area basiert flashback table auf den
UNDO-Einstellungen. Wie in Oracle9i ist die Größe des UNDO-Tablespaces und der
Initialisierungsparameter
UNDO_RETENTION
ausschlaggebend
dafür,
wie
weit
zurückgegangen werden kann. Neu in Oracle Database 10g ist eine zusätzliche Angabe von
RETENTION GUARANTEE beim Anlegen des UNDO-Tablespace. Dadurch wird garantiert,
dass zugunsten der Vorhaltezeit der Platz für flashback table reserviert bleibt. DMLOperationen, die den UNDO-Platz benötigen, könnten dann aus Platzmangel fehlschlagen.
Um eine einfache Handhabbarkeit zu gewährleisten, ist die Nutzung von flashback table ist
nicht nur auf SQL*Plus beschränkt sondern auch im Enterprise Manager (siehe Abb 3)
implementiert,
Abb 3: Flashback table Unterstützung im Enterprise Manager
Wie gerade gezeigt wurde, kann bei fehlerhaft durchgeführten DML-Kommandos flashback
table eingesetzt werden.
Was kann man bei versehentlich gelöschten Tabellen tun? Die Antwort liefert das Kommando
FLASHBACK TABLE
BEFORE DROP. Das nächste Kapitel gibt die notwendigen
Hintergrundinformationen dazu.
Oracles recycle bin oder das flashback drop- Konzept
Neu in Oracle Database10g ist die Einführung eines recycle bin. Bei einem DROP TABLEKommando werden jetzt automatisch die Tabellen und zugehörige Objekte wie Indizes,
Constraints (außer referentielle Integrität) und nested tables im sogenannten recycle bin zur
Verfügung gestellt. Dies geschieht durch ein einfaches Umbenennen der zugehörigen Objekte
und nicht durch explizites Kopieren in einen neuen Bereich.
Jeder User hat das Recht, seinen eigenen recycle bin zu selektieren, eigene Objekte aus dem
recycle bin wiederherzustellen oder den recycle bin mit einem PURGE-Kommando zu leeren.
Der recycle bin wird automatisch geleert, falls die Quota beim Erzeugen neuer Objekte
überschritten werden oder der User-Tablespace sich vergrößern müsste.
Folgendes Beispiel illustriert die Nutzung des recycle bins:
1) Löschen einer Tabelle:
SQL> DROP TABLE flash_tab;
Table dropped.
SQL> DROP TABLE TEST;
Table dropped.
2) Anzeigen des Inhalts des recycle bin:
SQL> SELECT object_name, original_name , type, droptime
2> FROM user_recyclebin;
OBJECT_NAME
----------------RB$$51954$TABLE$0
RB$$52045$INDEX$0
RB$$51957$TABLE$0
ORIGINAL_NAME
-------------TEST
TEST_IDX
FLASH_TAB
TYPE
-----------TABLE
NORMAL INDEX
TABLE
DROPTIME
------------------2003-10-22:21:48:42
2003-10-22:21:48:42
2003-10-21:19:20:35
RB$51957$TABLE$0 und RB$$51954$TABLE$0 sind die neuen systemgenerierten Namen für
die Tabellen TEST und FLASH_TAB. RB$$51954$TABLE$0 ist der Name, der verwendet
werden muss, um zum Beispiel die Tabelle TEST wiederherzustellen.
Die Integration im Enterprise Manager (siehe Abb 4) hilft den recycle bin zu durchsuchen und
die Tabelle wiederherzustellen.
Abb.4: Inhalt des recycle bins im Enterprise Manager
3) Durchführen des FLASHBACK TABLE- Kommandos:
SQL>FLASHBACK TABLE RB$$51954$TABLE$0 TO BEFORE DROP RENAME TO
2>TEST;
Flashback complete.
Nach Ausführung des Kommandos steht die Tabelle mit allen Daten wieder unter dem Namen
TEST und der Index unter dem vorher generierten Systemnamen RB$$52045$INDEX$0 zur
Verfügung.
Die Enterprise Manager Implementierung sieht folgendermaßen aus:
Abb. 5: Automatisches Umbennen im Enterprise Manager
Monitoring mit flashback query
Die mit Oracle9i flashback query eingeführten SQL-Erweiterungen ermöglichen es, Daten zu
einem speziellen früheren Zeitpunkt zu selektieren; das bedeutet eine einzige Version der Daten
kann pro Statement selektiert werden. Dies kann sinnvoll sein, um bei einer fehlerhaften
Dateneingabe diese durch ein entsprechendes Kommando wieder rückgängig machen zu können.
Folgendes Beispiel illustriert die in Oracle9i eingeführte flashback query-Funktionalität.
Der aktuelle Inhalt der Tabelle DEPT sieht folgendermaßen aus:
SQL> SELECT * FROM dept;
DEPTNO
---------10
20
30
40
DNAME
-------------ACCOUNTING
RESEARCH
SALES
OPERATIONS
LOC
------------NEW YORK
DALLAS
CHICAGO
BOSTON
Um die ursprüngliche Version der DEPT Tabelle zu selektieren, wird die SQL-Option AS OF
SCN oder AS OF TIMESTAMP genutzt.
SQL> SELECT * FROM dept AS OF TIMESTAMP
2> to_timestamp('21-10-2003 22:00:00','dd-mm-yyyy hh24:mi:ss');
DEPTNO DNAME
LOC
------------ --------------- ------------1 BU
MUC
10 ACCOUNTING
NEW YORK
20 RESEARCH
DALLAS
30 SALES
CHICAGO
40 OPERATIONS
BOSTON
Wie zu erkennen ist, enthält die DEPT Tabelle eine zusätzliche Zeile mit der DEPTNO 1.
Nun könnte mit dem entsprechenden INSERT-Kommando die versehentlich gelöschte Zeile in
Verbindung mit der AS OF Subquery wiedereingefügt werden.
Ist der Datenbestand allerdings mehrmals verändert worden, sind mit der Oracle9i-Technologie
mehrere flashback queries notwendig, um eine Übersicht zu bekommen.
Die neuen SQL-Erweiterungen VERSIONS BETWEEN SCN und VERSIONS BETWEEN
TIMESTAMP in Oracle Database 10g hingegen ermöglichen es, mehrere Versionen von Daten
auf einmal abzufragen und zusätzlich Informationen über die korrespondierenden Transaktionen
zu erhalten.
Das folgende Beispiel zeigt die verschiedenen Versionen der DEPTNO-Spalte und die
zugehörige Transaktions-ID:
SQL> SELECT deptno, dname, versions_operation o,
2> versions_xid, versions_starttime FROM dept
3> VERSIONS BETWEEN TIMESTAMP minvalue AND maxvalue
DEPTNO
---------11
1
10
20
30
40
DNAME
---------BU
BU
ACCOUNTING
RESEARCH
SALES
OPERATIONS
O
U
I
VERSIONS_XID
---------------0002001700004A22
0002001900004A1A
VERSIONS_STARTTIME
-------------------21-OCT-03 11.02.56 PM
21-OCT-03 10.52.52 PM
Pseudospalten wie VERSIONS_XID helfen, zusätzliche Informationen über die
Transaktionen zu erhalten. Weitere Beispiele für nützliche Pseudospalten zeigt die folgende
Liste:
· VERSIONS_STARTTIME: Startzeit bei Erzeugen der ersten Version
· VERSIONS_STARTSCN: Start-SCN der ersten Version
· VERSIONS_XID: Jede Version einer Zeile hat die eindeutige Transaction-ID der
Transaktion, die die Zeile erzeugt hat.
· VERSIONS_OPERATION: Operationskennziffer : U für UPDATE, D für DELETE
und I für INSERT
Die neue View DBA_TRANSACTION_QUERY liefert ähnlich wie die Logminer-View
V$LOGMNR_CONTENTS Informationen über das UNDO-SQL Statement.
SQL>SELECT xid,logon_user, table_name, table_owner, undo_sql
2>FROM dba_transaction_query WHERE table_owner='SCOTT';
XID
LOGON_USER TABLE_NAME TABLE_OWNER
---------------- ----------- ---------- ----------UNDO_SQL
-----------------------------------------------------------0002001700004A22
SCOTT
DEPT
SCOTT
update "SCOTT"."DEPT" set "DEPTNO" = '1' where ROWID =
'AAALwRAAEAAAAAMAAA';
0002001900004A1A
SCOTT
DEPT
SCOTT
delete from "SCOTT"."DEPT" where ROWID = 'AAALwRAAEAAAAAMAAA';
In unserem Beispiel kann durch Nutzung der zuvor ermittelten Transaktions-ID das UNDOStatement gefunden werden, um die Veränderungen an der Tabelle DEPT wieder rückgängig
zu machen.
SQL>SELECT logon_user, table_name, table_owner, undo_sql
2>FROM dba_transaction_query WHERE table_owner='SCOTT' AND
3> xid='0002001700004A22';
LOGON_USER TABLE_NAME TABLE_OWNER
---------------- ----------- ----------UNDO_SQL
-----------------------------------------------------------SCOTT
DEPT
SCOTT
update "SCOTT"."DEPT" set "DEPTNO" = '1' where ROWID =
'AAALwRAAEAAAAAMAAA';
Im Vergleich zu der flashback table- Technologie stellt diese Technik eine Alternative bei
versehentlich oder fehlerhaften Änderungen an Tabellendaten dar.
Fazit
Die Flashback- Features können in unterschiedlichen Bereichen bei logischen Korruptionen
eingesetzt werden. Nach Einstellung der entsprechenden Bereiche wie der flash recovery
area für flashback database und Undo-Management für flashback table und flashback query
übernimmt die Datenbank die Verwaltung dieser Speicherbereiche, die im Fehlerfall für das
Flashback eingesetzt werden.
Im folgenden wird eine kurze beispielhafte Übersicht über mögliche Fehlerursachen und
deren schnellen und einfachen Behebung durch die entsprechenden Flashback-Optionen
gegeben:
Korruptionen, die durch DROP USER, TRUNCATE TABLE, fehlerhaften Batchjobs die
mehrere Tabellen betreffen, können durch flashback database einfach und schnell auf
Datenbankebene behoben werden.
Fehler, die auf DROP TABLE beruhen, können durch den eigenen User recycle bin
rückgängig gemacht werden.
Versehentliche DML-Kommandos wie DELETE oder fehlerhaftes UPDATEs, die mit
COMMIT abgeschlossen sind, können durch flashback table oder flashback query in
Verbindung mit der Ausführung des UNDO-Statements behoben werden.
Batchjobs, die versehentlich mehrfach gelaufen sind und deren Fehlerursache noch nicht
bekannt ist, können durch flashback versions query bzw. flashback transaction query auditiert
werden.
Kontaktadresse:
Ulrike Schwinn
Oracle Deutschland GmbH
Riesstr 25
D-80992 München
Telefon:
+49(0)89 14301865
Fax:
+49(0)89 14301572
E-Mail
ulrike.schwinn@oracle.com
Internet: www.oracle.com/de