Die Zeitmaschine – Oracle Database 10g Flashback
Transcription
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 [email protected] Internet: www.oracle.com/de