DOAG Deutsche ORACLE-Anwendergruppe e.V.
|  
   
Home
DOAG
Mitgliedschaft
Events
Wissen
Presse

Flashback Database: Die Zeitmaschine ohne Datenverlust nutzen (Teil 2)

Flashback Database ermöglicht es Datenbankadministratoren, Datenbankzustände aus der Vergangenheit wiederherzustellen und unerwünschte Änderungen, wie das versehentliche Löschen von Datenbankobjekten, rückgängig zu machen. Mit einer Kombination aus Flashback Database, Data Pump und Recovery können zudem frühere Inhalte rekonstruiert werden, ohne zwischenzeitlich abgeschlossene Transaktionen zu verlieren.

Mit einer Kombination aus Flashback Database, Data Pump und Recovery können Sie frühere Inhalte rekonstruieren, ohne zwischenzeitlich abgeschlossene Transaktionen zu verlieren. Foto: Tfa1964

Nach einem flashback database-Befehl muss die Datenbank via resetlogs geöffnet werden. resetlogs bewirkt die Inkarnation der Datenbank in einen früheren Zustand. Dabei stehen alle nachtäglichen Änderungen nicht mehr zur Verfügung. Das kann ein Problem darstellen, wenn der Fehler nicht sofort bemerkt wird oder die Datenbank zwecks Wiederherstellung nicht sofort gestoppt werden kann. Denn die Nutzer arbeiten weiter mit der Datenbank (unten Umständen mit anderen Datenbankobjekten), fügen Daten hinzu, löschen, aktualisieren.

Mit einer Kombination aus Flashback Database, Data Pump und Recovery können frühere Inhalte rekonstruiert werden, ohne abgeschlossene Transaktionen zu verlieren. Dies weiß der DBA unserer fiktiven Firma.

Es ist dem DBA unmöglich, die Datenbank während der Hauptgeschäftszeit herunterzufahren um die gelöschte Tabelle wiederherzustellen. Also lässt er die Nutzer weiter arbeiten. Nun erfolgt folgende Transaktion:

  1. SQL> UPDATE HR.EMPLOYEES SET salary = salary *1,10;
  2. 107 rows updated.
  3. SQL> commit;
  4. Commit complete.

Zu einer späteren, passenden Zeit rollt der DBA die Datenbank auf die SCN vor dem truncate zurück. Dafür muss unser DBA erst mal die SCN abfragen. 

  1. SQL> SELECT current_scn FROM v$database;
  2. CURRENT_SCN
  3. ________
  4. 10436014
  5. SQL> TRUNCATE TABLE HR.JOB_HISTORY;
  6. TABLE truncated.

Im realen Leben kennt man die SCN vor Eintritt des Fehlers nicht; man ermittelt sie aus dem ungefähren Zeitpunkt des Fehlers und der Funktion timestamp_to_scn oder mit Hilfe des LogMiners.

Dann öffnet er die Datenbank read only und exportieren die intakteTabelle mit Data Pump.
 

  1. SQL> shutdown immediate;
  2. SQL> startup mount;
  3. SQL> flashback DATABASE TO scn 10436014;
  4. SQL> ALTER DATABASE open READ only;
  5. SQL> exit;

Je nach Datenmenge kann der Export länger dauern. Währenddessen steht die Datenbank für Abfragen, jedoch nicht für Änderungen zur Verfügung.

  1. [oracle@localhost ~]$ expdp HR TABLES=JOB_HISTORY directory=DATA_PUMP_DIR
  2. dumpfile=job_history.dmp
  3. Export: Release 11.2.0.2.0 - Production ON Mon Jan 2 16:17:50 2012
  4. Copyright (c) 1982, 2009, Oracle AND/OR its affiliates.  ALL rights reserved.
  5. Password:
  6. Connected TO: Oracle DATABASE 11g Enterprise Edition Release 11.2.0.2.0 - Production
  7. WITH the Partitioning, OLAP, DATA Mining AND Real Application Testing options
  8. Starting "HR"."SYS_EXPORT_TABLE_01":  HR/******** tables=JOB_HISTORY directory=DATA_PUMP_DIR dumpfile=job_history.dmp
  9. Estimate in progess using BLOCKS method...
  10. Processing object type TABLE_EXPORT/TABLE/TABLE
  11. Processing object type TABLE_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
  12. Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
  13. Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
  14. Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
  15. Processing object type TABLE_EXPORT/TABLE/COMMENT
  16. Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
  17. . . exported "HR"."JOB_HISTORY"                 7.054  KB    10 ROWS
  18. Master table "HR"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
  19. ***************************************************
  20. Dump file set for HR.SYS_EXPORT_TABLE_01 is:
  21. /home/oracle/app/oracle/admin/orcl/dpdump/job_history.dmp
  22. Job "HR"."SYS EXPORT TABLE 01" successfully completed at 16:19:35

Nach Abschluss des Exports öffnet der DBA die Datenbank im Mount-Modus und führt ein vollständiges recovery aus. Das Recovery versetzt die Datenbank in die Gegenwart und wiederholt dabei alle Änderungen, auch das Löschen des Tabelleninhalts. Der Inhalt wurde durch den Export gesichert.

  1. SQL> shutdown immediate;
  2. SQL> startup mount;
  3. SQL> recover DATABASE;
  4. SQL> ALTER DATABASE open;

Als letzten Schritt importiert er die Tabelle aus dem Export-Dump.


  1. [oracle@localhost ~]$ impdp HR TABLES=JOB_HISTORY directory=DATA_PUMP_DIR dumpfile=job_history.dmp TABLE_EXISTS_ACTION=APPEND
  2.  
  3. Import: Release 11.2.0.2.0 - Production ON Mon Jan 2 16:27:13 2012
  4. Copyright (c) 1982, 2009, Oracle AND/OR its affiliates. ALL rights reserved.
  5. Password:
  6.  
  7. Connected TO: Oracle DATABASE 11g Enterprise Edition Release 11.2.0.2.0 - Prodution
  8. WITH the Partitioning, OLAP, DATA Mining AND Real Application Testing options
  9. Master TABLE "HR"."SYS_IMPORT_TABLE_01" successfully loaded/unloaded
  10. Starting "HR"."SYS_IMPORT_TABLE_01":  HR/******** tables=JOB_HISTORY directory=DATA_PUMP_DIR dumpfile=job_history.dmp TABLE_EXISTS_ACTION=APPEND
  11. Processing object type TABLE_EXPORT/TABLE/TABLE
  12. Table "HR"."JOB_HISTORY" exists. Data will be appended to existing table but all dependent metadata will be skipped due to table_exists:action of append
  13. Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
  14. . . imported "HR"."JOB_HISTORY"       7.054 KB   10 rows
  15. Processing object type TABLE_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
  16. Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
  17. Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
  18. Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
  19. Processing object type TABLE_EXPORT/TABLE/COMMENT
  20. Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
  21. Job "HR"."SYS_IMPORT_TABLE_01" successfully completed at 16:29:12

Die unerwünschten Änderungen wurden zurückgesetzt, alle abgeschlossenen Transaktionen  wiederhergestellt.

Aufräumen in Testdatenbanken mit Flashback Database und garantierten Restore Points

Nach jedem Testlauf müssen Änderungen verworfen und Testdaten geladen werden. Diese Arbeiten können mit einer Kombination aus garantierten Restore Points und Flashback Database vereinfacht und beschleunigt werden. Garantierte Restore Points sind aussagekräftige Bezeichner für System Change Number, oder einfacher, Namen für Datenbankzustände, die man festhalten möchte. Man kann zum Beispiel den Restore Point clean_state vor Beginn der Testphase definieren. Die Datenbank stellt sicher, dass dieser Zustand wiederhergestellt werden kann.

Für die Nutzung von Flashback Database und garantierten Restore Points müssen folgende Voraussetzungen erfüllt sein:

  • die Datenbank befindet sich im Archivelog Modus,
  • die Fast Recovery Area wurde konfiguriert,
  • Flashback Logging kann (muss aber nicht) aktiv sein.

Es ist eine gute Idee, vor der Erzeugung des garantierten Restore Points das Flashback Logging zu deaktivieren. Denn in diesem Fall speichern die Flashback Logs nur die Version der Datenblöcke zur Zeit des garantierten Restore Points, nicht die gesamte Änderungshistorie. Die Datenbank kann auf den garantierten Restore Point zurückgerollt werden und es wird weniger Platz für Flashback Logs benötigt. So deaktiviert man das Flashback Logging:

  1. SQL> ALTER DATABASE flashback off;
  2. DATABASE altered.
  3. SQL> SELECT flashback_on FROM v$database;
  4. FLASHBACK_ON
  5. _____________
  6. RESTORE POINT ONLY

Wenn Flashback Logging deaktiviert wurde, muss die Datenbank in den Mount-Modus versetzt werden, bevor der erste garantierte Restore Point definiert wird.

  1. SQL> shutdown immediate;
  2. SQL> startup mount;
  3. SQL> CREATE restore point clean_state guarantee flashback DATABASE;

Wenn Flashback Logging aktiv ist, erzwingt der garantierte Restore Point die Aufbewahrung aller Flashback Logs. Der Vorteil: Man kann auf jeden Zeitpunkt nach Erzeugung des garantierten Restore Points zurückkehren. Allerdings können Flashback Logs nicht mehr automatisch überschrieben werden.

Sollte die FRA vollaufen, steht die Datenbank still. Um das zu verhindern, ist es wichtig den freien Platz in der FRA zu überwachen. Dazu dient die Sicht V$RECOVERY_AREA_USAGE.

Zurück zu unserem DBA: Er hat den Startzustand mit einem garantierten Restore Point versehen.  Nun kann er mit der eigentlichen Testphase beginnen und Daten und Datenbankobjekte verändern. Soll der Initialzustand wiederhergestellt werden, reicht ein flashback database auf den definierten Restore Point.

  1. # Aendern - Testen
  2. SQL> shutdown immediate;
  3. SQL> startup mount;
  4. SQL> flashback DATABASE TO restore point clean_state;
  5. SQL> ALTER DATABASE open resetlogs;

Wenn sie nicht mehr benötigt werden, müssen garantierte Restore Points explizit gelöscht werden. Somit steht in der FRA der von den Flashback Logs belegte Platz wieder zur Verfügung.

  1. SQL> DROP restore point clean_state;
  2. Restore point dropped.

Garantierte Restore Points sind eine Alternative zu Storage-Snapshots. Mit Mitteln der Datenbank kann ein besonderer Zustand der Datenbank festgehalten und wiederhergestellt werden - sei es der Testbeginn oder ein Anwendungsupgrade mit Auswirkungen auf die Datenbank.

Kann der gewünschte Zustand mittels Flashback Database wiederhergestellt werden? 

Wenn die benötigten Flashback Logs in der Fast Recovery Area vorgefunden werden, kann der gewünschte Zustand mittels Flashback Database wiederhergestellt werden. Die Flashback Logs teilen sich den Platz mit Sicherungsdateien. Oracle alleine entscheidet über ihre Lebensdauer, in Abhängigkeit vom verfügbaren Platz und der Aufbewahrungsfrist für Sicherungen. Ist FRA nicht groß genug, werden die älteren Flashback Logs durch neue überschrieben. Flasback Logs können nicht archiviert werden. Man kann den angestrebten Wiederherstellungszeitraum in  den Initialisierungsparameter DB_FLASHBACK_RETENTION_TARGET angeben:

  1. SQL> ALTER system SET DB_FLASHBACK_RETENTION_TARGET = 720;

Der DBA unserer fiktiven Firma soll die Datenbank innerhalb der  letzten 720 Minuten (12 Stunden) zurücksetzen. Der Standardwert ist 1440 Minuten (1 Tag), wobei die Erfahrung sagt, dass 3 Tage (4320 Minuten) der optimale Wert ist. Es stellt sicher, dass unerwünschte Änderungen vom Wochenende Montagmorgen schnell rückgängig gemacht werden können. Wie der Name sagt, ist DB_FLASHBACK_RETENTION_TARGET nur ein Ziel. Es wird eingehalten, wenn ausreichend Platz zur Verfügung steht. Sonst wird der folgende Fehler zurückgeworfen und Point in Time Recovery bleibt die einzige Möglichkeit, den alten Zustand wiederherzustellen:

  1. SQL> flashback DATABASE TO timestamp systimestamp - interval '3' day;
  2. flashback DATABASE TO timestamp systimestamp - interval '3' day
  3. *
  4. ERROR at line 1:
  5. ORA-38729: NOT enough flashback DATABASE log DATA TO do FLASHBACK.

Wieviel Platz sollte man für die Flashback Logs in der FRA vorsehen? 

Die Größe der Flashback Logs hängt von der Aktivität der Datenbank ab. Es entspricht ungefähr dem Volumen der Archived Redo Logs im selben Zeitraum. Möchte man Flashback Logs über einen Zeitraum von 12 Stunden aufbewahren, kann man beobachten, wieviel Redo in einem Intervall von 12 Stunden, bei ähnlicher Arbeitslast generiert wurde und die FRA entsprechend dimensionieren.

Ein Hilfsmittel ist auch die Sicht V$FLASHBACK_DATABASE_LOG. Bereits 2-3 Stunden nach Einschalten von Flashback Logging liefert sie eine gute Schätzung des Platzbedarfs für Flashback Logs für das eingestellte Aufbewahrungziel. ESTIMATED_FLASHBACK_SIZE (in Byte) ist der benötigte Platz, FLASHBACK_SIZE der aktuell vorhandene Platz. Die zwei Werte beziehen sich nur auf den Speicherbedarf für Flashback Logs und nicht für die gesamte FRA.

  1. SQL> SELECT FLASHBACK_SIZE, ESTIMATED_FLASHBACK_SIZE, RETENTION_TARGET FROM V$FLASHBACK_DATABASE_LOG;
  2.  
  3. FLASHBACK_SIZE ESTIMATED_FLASHBACK_SIZE RETENTION_TARGET
  4. ----------------  ----------------  ----------------
  5. 12164864               111759369                720

 

Die Datenbank verfügt über ein eigenes Versionsmanagementsystem. Mit Flashback Database kann ein früherer Zustand der gesamten Datenbank schnell wiederhergestellt werden. Flashback Database ist eine intelligente Recovery-Strategie, um unerwünschte  Operationen (DML und DDL) rückgängig zu machen. Garantierte Restore Points  sind eine attraktive Alternative zu Storage-Snapshots, um einen Zustand der Datenbank zu schützen.

Statt vor Beginn eines Tests oder vor der Durchführung einer kritischen Operation (z.B. Upgrade der Anwendung oder der Datenbank) einen Storage-Snapshot zu ziehen, kann man einen Garantierten Restore Point erzeugen. So können Anwender sicher sein, dass sie jederzeit auf den gesicherten Zustand zurückkehren können.  Oracle hat Flashback Database in der Version 10g der Oracle Datenbank eingeführt und stellt die Funktion ausschließlich in der Enterprise Edition zur Verfügung.

Und Ihre Meinung? Diskutieren Sie mit!

Noch keine Kommentare
  Bitte melden Sie sich an: Ihr Kommentar

Hinweis
Um einen Kommentar abzugeben, müssen Sie eingeloggt oder registriert sein. Die Kommentare werden vor Veröffentlichung redaktionell geprüft. Mit dem Login akzeptieren Sie unsere Richtlinien.
Legen Sie kostenlos ein Benutzerkonto an: Registrierung oder melden Sie sich an: Login

Kennwort oder Benutzername vergessen?
Wir schicken Ihnen Ihre Zugangsdaten an Ihre E-Mail-Adresse:


01.02.2012 Datenbank
Von: Ileana Somesan
Zurück