Backup und Recovery mit Oracle 10g (Teil II):

Total Recall mit Oracle Flashback

In der letzten ORDIX News beschäftigten wir uns mit allgemeinen Neuerungen bei Backup und Recovery. Diesmal behandeln wir das Thema Flashback. Flashback ist in Oracle 10g fundamental erweitert worden. Die wichtigsten Neuerungen stellen wir in diesem Artikel dar.

Änderungen verfolgen

Mit Oracle 9.2 wurde die Flashback-Query als AS OF Klausel des SELECT-Statements eingeführt. Es war und ist also möglich, sich auf Basis der UNDO-Segmente die historischen Datenbestände einzelner Tabellen anzuschauen. Diese Funktionalität ist mit Oracle 10g erweitert und auf die gesamte Datenbank ausgedehnt worden.

Dabei unterscheiden wir drei Bereiche:

• Datensätze (Flashback Query - Flashback Row)
• Ganze Tabellen (Flashback Table)
• Die gesamte Datenbank (Flashback Database)

Datensätze

Die Flashback Funktionalität wurde mit Oracle 10g derart erweitert, dass es möglich ist, UNDO Informationen (Statements) zu erhalten, ohne den LogMiner einsetzen zu müssen. Dazu gibt es die neue View FLASHBACK_TRANSACTION_QUERY. Diese View enthält die Spalte UNDO_SQL, über die das Statement zurückgeneriert werden kann. Das erste in Abbildung 1 dargestellte SELECT-Statement zeigt eine beispielhafte Ausgabe.

select undo_sql
from flashback_transaction_query
where xid = '040013000D000100';

UNDO_SQL
------------------------------------------------------------------------
update "AK"."A" set "NAME" = 'Otto' where ROWID = 'AAACqZAAGAAAAAqABF';

select versions_xid, a, name
from ak.ma versions between scn minvalue and maxvalue
where name = 'Otto'

VERSIONS_XID              A NAME
---------------- ---------- --------------------
040013000D000100          1 Otto

Das zweite SELECT-Statement in Abbildung 1 dient der Ermittlung der XID, die für das Ermitteln des richtigen Statements in der where-Klausel gebraucht wird.

Dieses Statement zeigt uns zugleich die Erweiterung der Flashback-Query um versions between. Mit versions between und den beiden symbolischen Werten minvalue und maxvalue werden alle in den UNDO-Segmenten noch zur Verfügung stehenden alten Werte angezeigt.

Ganze Tabellen

Voraussetzung für das Zurücksetzen von Tabellen ist das eingeschaltete ROW MOVEMENT auf der betreffenden Tabelle.

ALTER TABLE <tablename> ENABLE ROW MOVEMENT;

Als Kriterium für das Zurücksetzen können wir die System Change Number (SCN) oder einen Zeitpunkt verwenden.

FLASHBACK TABLE <tablename> [,...] to {SCN <n> | TIMESTAMP <t>}

Die Uhrzeit, auf die wir zurücksetzen wollen, lässt sich, wie in Abbildung 1, mit einer Flashback-Query ermitteln.

Ein Flashback Table Statement zeigt Abbildung 2.

flashback table ma to timestamp to_timestamp 
('06.12.04 20:14:04', 'dd.mm.yy hh24:mi:ss');

Auch hier stammen alle alten Werte aus den UNDO-Segmenten. Damit ist natürlich auch klar, dass sich damit das Rad nicht beliebig weit zurückdrehen lässt. Der darstellbare Zeitraum hängt vom Transaktionsvolumen und der Größe des UNDO-Tablespaces ab. Außerdem ist natürlich nur ein Zurücksetzen von Tabellen auf Basis der internen Konsistenzen möglich. Sollten also durch den Versuch eines Flashback Table Constraints verletzt werden, so wird dieser Versuch mit einer Fehlermeldung abgelehnt.

Auch eine gelöschte Tabelle lässt sich mit Oracle 10g zurückholen. Damit das funktioniert, hat Oracle das Standard Verhalten des Kommandos drop table <tablename>; geändert.

Was beinhaltet das im Einzelnen?

• Die DataDictionary Einträge der Tabelle werden nicht mehr gelöscht, sondern umbenannt.
• Die von der Tabelle allokierten Extents werden nicht freigegeben.
• Dies gilt auch für alle auf der Tabelle definierten Indizes.
• Der belegte Platz wird weiterhin der Quota des Eigentümers hinzugerechnet.
• Die Informationen werden mit sprechendem Namen im RECYCLEBIN gehalten.

In Abbildung 3 sehen wir, dass die bisherige Tabelle TEST unter einem BIN$... Namen weiterlebt. Die Daten der Tabelle stehen read-only über den in der Spalte „RECYCLEBIN NAME“ genannten Namen zur Verfügung.

DROP TABLE test;

show recyclebin

ORIGINAL NAME RECYCLEBIN NAME                OBJECT TYPE  DROP TIME
------------- ------------------------------ ------------ -------------------
TEST          BIN$22fQU+CVGe5gMBEKAQGPKR==$0 TABLE        2004-12-07:20:04:23
	

Mit dem Kommando FLASHBACK TABLE test TO BEFORE DROP; holen wir die Tabelle TEST zurück. Gleichzeitig wird sie aus dem RECYCLEBIN entfernt. RECYCLEBIN ist eine View des Data Dictionary. In ihr werden die Informationen über gelöschte Objekte gespeichert.

Um eine Tabelle wirklich zu löschen, führen wir das Kommando DROP TABLE mit der Option PURGE aus:

drop table <tablename> purge;

Stellt sich nur noch die Frage, wie nun der RECYCLEBIN zu leeren ist? Dazu gibt es das neue Kommando purge.Dieses Kommando gibt es in verschiedenen Abstufungen:

• purge {table <tablename> | index <indexname>} Um einzelne Objekte aus dem RECYCLEBIN zu löschen.
• purge tablespace <tablespacename> [user <username>] Um alle Objekte bzgl. eines Tablespaces aus dem RECYCLEBIN zu löschen. Mit der Option user lässt sich dieses auf die Objekte eines Benutzers des betroffenen Tablespace beschränken.
• Mit purge recyclebin kann jeder User seinen eigenen RECYCLEBIN löschen.

Die ganze Datenbank

Die letzte Neuerung im Zusammenhang mit Flashback ermöglicht, die ganze Datenbank, wie mit einem Schieber, entlang des Zeitstrahls zurückzusetzen. Eine durchaus zeitsparende Alternative zum Point In Time Recovery (siehe Abbildung 4).

Um Flashback Database nutzen zu können, müssen drei Voraussetzungen erfüllt sein:

1. Die Datenbank muss in der Betriebsart Archivelog laufen.
2. Die folgenden Parameter müssen gesetzt sein, um Ort und Größe der Flash Recovery Area zu bestimmen, in die die anfallenden Flashback Logs geschrieben werden:
   • DB_RECOVERY_FILE_DEST und
   • DB_RECOVERY_FILE_DEST_SIZE = 0
   • Über den Parameter DB_FLASHBACK_RETENTION_TARGET definieren wir die Zeitspanne, die wir maximal zurückgehen wollen. Dieser Parameter steht standardmäßig auf 1440 Minuten (1 Tag).
3. Nach diesen Vorbereitungen können wir das neue Feature einschalten. Dazu benötigen wir ein Wartungsfenster, um mit dem Kommando alter database flashback on; in der mount-Phase den Flashback Modus einzuschalten.

   Die Aktivierung überprüfen wir in der View v$database:
   select flashback_on from v$database;

Das Monitoring unserer neuen Funktionalität erfolgt über die Views v$flashback_database_log (siehe Abbildung 5) und v$flashback_database_stat (siehe Abbildung 6).

SELECT * FROM v$flashback_database_log;

OLDEST_       OLDEST_         RETENTION_TARGET FLASHBACK_SIZE ESTIMATED_
FLASHBACK_SCN FLASHBACK_TIME                                  FLASHBACK_SIZE
------------- --------------- ---------------- -------------- --------------
       195112        08.12.04             1440        8192000        4000000

SELECT * FROM v$flashback_database_stat;

BEGIN_TIME END_TIME FLASHBACK_DATA DB_DATA REDO_DATA ESTIMATED_FLASHBACK_SIZE
---------- -------- -------------- ------- --------- ------------------------
08.12.04   08.12.04           8192       0         0                        0

Mit der View v$flashback_database_log lässt sich ermitteln, bis zu welchem Zeitpunkt wir die Datenbank zurücksetzen können und ob der verfügbare Platz in der Flash Recovery Area bei der aktuellen Last ausreicht, um das gewünschte Zeitfenster abzubilden.

In der View v$flashback_database_stat werden für die letzten 24 Stunden, jeweils aufsummiert für eine Stunde, neben der geschätzten Flashback Größe folgende Werte angezeigt:

• geschriebene Flashback Daten in Byte
• gelesene und geschriebene Datenbank Daten
• geschriebene Redo Daten in Byte

Flashback Database lässt sich sowohl bei SQL*Plus als auch bei RMAN verwenden. Zwei Beispiele:

SQL> flashback database to timestamp (sysdate -1/24);

RMAN> flashback database to scn 12345;

Mit dem SQL-Beispiel wird die Datenbank um 1 Stunde zurückgesetzt, mit dem RMAN-Beispiel auf die angegebene SCN.

Wie macht Oracle das technisch? Durch das Aktivieren der Flashback Database Funktionalität wird ein zusätzlicher Prozess, der Recovery Writer (RVWR) gestartet (siehe Abbildung 7).

Die durch den RVWR geschriebenen Flashback Database Logs liegen in der Flash Recovery Area und enthalten die Before Images auf Block Ebene. Die Flashback Recovery Logs werden nicht archiviert, sondern von Oracle nach Überschreiten der mit DB_FLASHBACK_RETENTION_TARGET gesetzten Zeitspanne gelöscht.

Mit Hilfe der Before Images und den Redo Informationen kann die Datenbank somit auf jeden beliebigen Zeitpunkt innerhalb des eingestellten Zeitfensters zurückgesetzt werden. Um beispielsweise ein Zurücksetzen von 18 Stunden zu ermöglichen, sind natürlich dann auch die entsprechenden, archivierten RedoLog Dateien auf dem Server vorzuhalten.

Das erklärt, wie der Schieberegler in Abbildung 4 zu verstehen ist.

Vor der Freigabe der Datenbank für die Benutzer sollte die Datenbank READ ONLY geöffnet werden, um die Richtigkeit des Zurücksetz-Zeitpunktes zu überprüfen.

Fazit

Auch wenn Flashback Database zunächst Kosten in Form von zusätzlichen Platten bedeutet, ist es eine reizvolle Alternative zu bisherigen Sicherungen in Form von Plattenspiegeln. Weiterhin ermöglicht es, nach einem Fehlversuch (falscher Rücksetz-Zeitpunkt) einen erneuten Versuch ohne größere Klimmzüge zu starten.

Der einzige Wermutstropfen beim Thema Flashback ist die geänderte Funktionalität beim DROP TABLE Kommando. Das Verhalten des Kommandos ist derart verändert, dass bei einer Migration unter Umständen unzählige Skripte geändert werden müssen, um das gewohnte Verhalten sicherzustellen. Dadurch wird dem DBA ein erheblicher Mehraufwand zugemutet.

In der nächsten Ausgabe beschäftigen wir uns mit den Neuerungen beim Recovery Manager und DataGuard und werden damit das Thema Backup und Recovery abschließen.

Andreas Kother (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen