Überall liest man, wie toll das Automatische Block Media Recovery der Oracle 11g Release 2 ist. Das ist sicherlich wahr, allerdings mit dem Nachteil, dass man dafür die recht teure Active Data Guard Option lizenziert haben muss. Aber muss das wirklich sein?
Nein!
Block Media Recovery funktioniert auch ohne Active Data Guard – allerdings nicht automatisch, sondern man muss einen “ganz schweren” Befehl eingeben
… und wie funktioniert das jetzt?
Das ganze Prozedere wird sicherlich an einem Beispiel deutlicher. Dafür müssen wir allerdings erst mal eine Datendatei “kaputt” machen. Dafür wird ein Tablespace (corruptts) angelegt und eine einfache Tabelle (corrupt_table). Den Headerblock der Tabelle wollen wir so ändern, dass mit einem SELECT Befehl die Korruption erkannt werden kann.
SQL> CREATE TABLESPACE kaputtes_ts
DATAFILE SIZE 10M;
SQL> CREATE TABLE kaputte_tabelle
TABLESPACE kaputtes_ts
AS SELECT * FROM ALL_TABLES;
SQL> SELECT header_file, header_block
FROM dba_segments
WHERE segment_name = 'KAPUTTE_TABELLE';
HEADER_FILE HEADER_BLOCK
----------- ------------
9 130
Und jetzt wird kaputt gemacht …
Wenn die Datenbankdateien in einem normalen Filesystem liegen, kann man mit dem UNIX Befehl dd einfach die Datei kaputt schreiben. Wenn allerdings ASM verwendet wird, ist das etwas schwieriger. Am besten erstellt man erst eine Kopie der Datendatei in einem “normalen” Filesystem (z.B. /tmp) und anschließend wird in dieser Datei am Besten der oben angegebene Headerblock der Tabelle corrupt_table mit etwas nettem überschrieben
RMAN> BACKUP AS COPY TABLESPACE kaputte_ts
FORMAT '/tmp/kaputte_ts.bck';
$ dd of=/tmp/kaputte_ts.bck bs=8192 conv=notrunc seek=130 << EOF
ein schöner Text ...
EOF
Jetzt wird der Datenbank diese korrupte Datei “untergeschoben” (wenn die Datenbank im Filesystem liegt, ist das nicht erforderlich).
SQL> ALTER TABLESPACE kaputte_ts OFFLINE;
RMAN> RUN {
SET MAXCORRUPT FOR DATAFILE 9 TO 2;
RESTORE TABLESPACE kaputte_ts;
RECOVER TABLESPACE kaputte_ts;
};
SQL> ALTER TABLESPACE kaputte_ts ONLINE;
Mal sehen, ob die Datei wirklich kaputt ist…
SQL> SELECT * FROM kaputte_tabelle;
SELECT * FROM kaputte_tabelle
*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 9, block # 130)
ORA-01110: data file 9: '+DATA01/jalin11/datafile/kaputte_ts.862.790151237'
Recovery mit dem RMAN und der Standby Datenbank
Wie ja aus meinen anderen Blocks schon bekannt, bin ich ein absoluter RMAN Fan. Und auch hier ist der RMAN unschlagbar. Zwar gibt es die Möglichkeit, direkt Blöcke anzugeben, die repariert werden sollen, aber man kann dem RMAN auch sagen, dass er einfach alle gefundenen Blöcke reparieren soll. Dafür müssen die Blöcke allerdings erkannt worden sein. Wie in dem obigen Beispiel durch den SELECT auf die Tabelle corrupt_table wird jeder gefundene korrupte Block in die Tabelle v$database_block_corruption eingetragen und kann entsprechend auch abgefragt werden:
SQL> SELECT *
FROM v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ ---------
9 130 1 0 CORRUPT
Wie bereits erwähnt, soll für die Wiederherstellung eine Standby Datenbank verwendet werden und nicht ein bereits erstelltes Backup oder z.B. Flashback Logs.
Voraussetzung ist allerdings, dass die Datenbanken (Primär und Standby) im Recovery Manager Catalog registriert sind, denn nur über diesen kann festgestellt werden, dass es eine Beziehung zwischen den Datenbanken gibt. Außerdem muss für diese Aktion die Standby Datenbank geöffnet werden (allerdings nur Read Only).
WICHTIG
Bevor die Standby Datenbank geöffnet wird, muss der Log-Apply Prozess beendet werden, ansonsten würde die Datenbank als Active Data Guard geöffnet werden und Oracle würde sich über zusätzliche Lizenzen freuen.
Da ich davon ausgehe, dass Sie Ihre Standby Datenbanken über den Data Guard Broker verwalten, sollte der Log Apply auch über den Data Guard Broker beendet werden und dann kann die Datenbank geöffnet werden. Die Option “READ ONLY” ist nicht erforderlich, da die Datenbank aufgrund der Controlfile “weiß”, dass es sich um eine Standby Datenbank handelt.
DGMGRL> EDIT DATABASE 'JALIN11_DG' SET STATE='apply-off'; SQL> ALTER DATABASE OPEN;
Jetzt steht dem Recovery nichts mehr im Wege.
$ rman RMAN> CONNECT TARGET sys/manager@JALIN11 RMAN> CONNECT CATALOG rman/manager@RCAT RMAN> RECOVER CORRUPTION LIST; Starting recover at 01-AUG-12 using channel ORA_DISK_1 finished standby search, restored 1 blocks starting media recovery media recovery complete, elapsed time: 00:00:03 Finished recover at 01-AUG-12
Das war’s!
Nur der Befehl RECOVER CORRUPTION LIST sorgt dafür, dass die Blöcke wieder repariert werden. An der unscheinbaren Meldung “finished standby search” erkennt man, dass der Block von der Standby Datenbank gelesen wurde.
Jetzt muss nur noch die Standby Datenbank wieder in den Recovery Modus zurückgesetzt werden und der Apply-Prozess wieder gestartet werden.
Viel Erfolg und über Kommentare würde ich mich wie immer freuen.