Nachdem im letzten Recovery Manager Tipp das Thema Backup ausführlich behandelt wurde, geht es in diesem Tipp darum, wie Sie mit Hilfe dieser Backups ein Recovery durchführen.
Zwar sollte mit Oracle 11g der Recovery Advisor verwendet werden, um die optimale Wiederherstellungsstrategie zu finden, aber es gibt ein paar nützliche Funktionalitäten, wenn das Restore manuell durchgeführt wird. Hierzu gehört unter anderem das Restore an einen anderen Speicherort bzw. auf eine andere Diskgruppe in ASM.

Der Vollständigkeit halber werden die Grundlagen des Restores nochmals aufgelistet, wie das Recovery nach Verlust des SPFiles, eines Controlfiles, einer Datendatei und eines Redolog Members.

Als Basis für die erweiterten Themen und den Umzug während des Restores dient wieder die "Minimalkonfiguration" einer Datenbank anhand derer die unterschiedlichen Ausfallszenarien dargestellt werden:

• Verlust des Software Homes (Speicherort 1)
• Verlust aller Datendateien (Speicherort 2) und optionalen Restore auf einen anderen Speicherort
• Verlust der Flashback Recovery Area (FRA: Speicherort 3) und Änderung der FRA Lokation
• "Worst Case Szenario": Verlust aller Datendateien, Online Redologs und FRA

Minimalkonfiguration

Wie im vorhergehenden Tipp besprochen, sollte eine Minimalkonfiguration aus mindestens 3 unabhängigen Platten bzw. 3 unabhängigen RAID Systemen bestehen, ob nun mit oder ohne ASM. Rot gekennzeichnete Dateien werden dabei nicht von RMAN mit gesichert:

Speicherort 1 (Erste Platte z.B. sda1)	Speicherort 2 (Zweite Platte z.B. sda2)	Speicherort 3 (Dritte Platte z.B. sda3) Flash Recovery Area enthält:
Software Passwortfile Logfiles/Diag Verzeichnis SPFile 1. Controlfile	2. Controlfile Datenfiles (System-, Undo-, User- Tablespaces) Redolog Member 1	3. Controlfile Redolog Member 2 Archivierte Redologs Backup

Diese Konfiguration gewährleistet, dass beim kompletten Verlust eines Speicherortes immer ein vollständiges Restore ohne jeglichen Datenverlust erfolgen kann. Deswegen sind Szenarien wie der "Verlust aller Controlfiles" und der "Verlust aller Online Redologs" sehr unwahrscheinlich. Maximal ein "Worst Case Szenario", d.h. der Verlust aller Platten und das Zurückgreifen auf ein Backup von Band/externe Platte sollte noch näher betrachtet werden.
Alle Szenarien basieren hierbei auf den Informationen des RMAN Katalog im Controlfile und dem damit verbundenen automatischem Backup von SPFile und Controlfile (Autobackup). Des Weiteren gehen die Szenarien von der Verwendung der FRA aus. Beachten Sie, dass sich einige der Restore Szenarien unterscheiden, wenn eine Datenbank als Recovery Katalog verwendet wird oder wenn nicht die FRA das Backup und Autobackup enthält.
Bevor Sie selber mit Testen anfangen, sollte geprüft werden, ob Ihr Backup auch vollständig ist und den Anforderungen Ihrer Backupstrategie entspricht.

RMAN> REPORT UNRECOVERABLE
...
RMAN> REPORT NEED BACKUP

Recovery nach Verlust oder Korruption des SPFiles

Ist das SPFile korrupt oder gelöscht, so kann die Datenbank nicht mehr gestartet werden. Folgende Fehler deuten auf ein Problem mit dem SPFile hin: "ORA-01078" gefolgt von einem "LRM-00109: could not open parameter file". Mit wenigen RMAN Befehlen wird das SPFile aus dem Autobackup wiederhergestellt. Da in folgendem Beispiel die FRA verwendet wird, ist kein SET DBID notwendig.

RMAN> STARTUP
RMAN> RESTORE SPFILE FROM AUTOBACKUP RECOVERY AREA 'd:\oracle\fra' DB_NAME 'ORCL';
RMAN> SHUTDOWN IMMEDIATE
RMAN> STARTUP

Recovery nach Verlust oder Korruption eines Controlfile

Sind nicht alle Controlfiles korrupt oder gelöscht, empfiehlt es sich, von einem funktionierenden Controlfile einfach eine Kopie über RMAN zu erzeugen. Welches Controlfile noch funktioniert, bzw. welche Controlfiles korrupt sind, erfährt man aus dem Alert.log der Datenbank. Ein "RESTORE FROM AUTOBACKUP" ist nur beim Verlust aller Controlfiles empfohlen, da nach einem solchen Recovery die Datenbank mit "RESETLOGS" geöffnet werden muss. Ein "ORA-00205: error in identifying control file , check alert log for more info" deutet auf den Verlust eines Controlfile hin.

RMAN> RESTORE CONTROLFILE FROM 'D:\ORACLE\ORADATA\ORCL\CONTROL02.CTL';
RMAN> STARTUP

Recovery nach Verlust, Korruption einer Datendatei oder eines Tablespaces

Korrupte oder nicht vorhandene Tablespaces werden mit einem "ORA-01157", gefolgt von einem "ORA-01110: data file 4" quittiert.
Es gibt sehr elegante Möglichkeiten korrupte Tablespaces / Datendateien auch online wiederherzustellen (Siehe hierzu auch die RMAN Dokumentation). Dies funktioniert aber nicht für SYSTEM oder UNDO Tablespace. Deswegen ist hier die Variante aufgelistet, die beliebige Tablespaces/Datendateien wiederherstellt:

RMAN> RESTORE DATAFILE 'D:\ORACLE\ORADATA\ORCL\USERS01.DBF';
RMAN> RECOVER DATAFILE 'D:\ORACLE\ORADATA\ORCL\USERS01.DBF';

Recovery nach Verlust, Korruption eines Redolog Members

Anders als bei den vorhergehenden Fällen hat der Verlust / die Korruption eines Redolog Members keine direkt sichtbaren Auswirkungen beim Datenbank Startup. Ein Fehler ist nur anhand eines ORA-00313 im Alert.log der Datenbank sichtbar. Trotzdem sollte der Fehler so schnell wie möglich behoben werden, da ansonsten im Falle eines Plattenausfalles keine Garantie mehr besteht, die aktuellsten Transaktionen retten zu können.
Dieser Fehler wird nicht direkt in RMAN behoben, sondern während des laufenden Betriebs in SQL:

SQL> ALTER DATABASE DROP LOGFILE MEMBER 'D:\ORACLE\ORADATA\ORCL\REDO03B.LOG';
SQL> ALTER DATABASE ADD LOGFILE MEMBER 'D:\ORACLE\ORADATA\ORCL\REDO03B.LOG' REUSE TO GROUP 3;

Beim Droppen der aktiven Log Gruppe kommt es zu einer Fehlermeldung:
ALTER DATABASE DROP LOGFILE MEMBER 'D:\ORACLE\ORADATA\ORCL\REDO03B.LOG'
*
ERROR at line 1:
ORA-01609: log 1 is the current log for thread 1 - cannot drop members
ORA-00312: online log 1 thread 1: 'D:\ORACLE\ORADATA\ORCL\REDO03.LOG'
ORA-00312: online log 1 thread 1: 'D:\ORACLE\ORADATA\ORCL\REDO03B.LOG'

Zur Abhilfe muss vorher die Log Gruppe gewechselt werden
SQL> ALTER SYSTEM SWITCH LOGFILE;

Recovery nach Verlust des kompletten 1. Speicherortes

In diesem Fall bedeutet das den Verlust des Software Home, Passwort File, SPFile und einer Controldatei und wahrscheinlich auch des Betriebssystems. Die Wiederherstellung des OS und die Installation der Oracle Software (mit denselben Patches!) ist hierbei nicht Gegenstand dieses Artikels und kann im Notfall über eine Neuinstallation bewerkstelligt werden.
Die Passwortdatei lässt sich unter /database folgendermaßen erzeugen. Bei Unix/Linux unter /dbs und mit einfachen Hochkommata ' ':

orapwd file="PWDorcl.ora" password=oracle entries=5 force=y ignorecase=y nosysdba=n

oradim -NEW -SID ORCL -SYSPWD oracle

RMAN> STARTUP
RMAN> RESTORE SPFILE FROM AUTOBACKUP RECOVERY AREA 'd:\oracle\fra' DB_NAME 'ORCL';
RMAN> SHUTDOWN IMMEDIATE;
RMAN> STARTUP
RMAN> RESTORE CONTROLFILE FROM 'D:\ORACLE\ORADATA\ORCL\CONTROL02.CTL';
RMAN> STARTUP

$ emca -config dbcontrol db 

SQL> STARTUP
RMAN> RESTORE CONTROLFILE FROM '+FRA/orcl/controlfile/current.256.711977159';
RMAN> STARTUP MOUNT;
RMAN> RESTORE DATABASE
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN;

SQL> STARTUP NOMOUNT;
SQL> ALTER SYSTEM SET CONTROL_FILES='+FRA/orcl/controlfile/current.256.711977159','+NEUDATA' SCOPE=spfile SID='*';
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP NOMOUNT;
RMAN> RESTORE CONTROLFILE FROM '+FRA/orcl/controlfile/current.256.711977159';
Speziell für ASM muss nach einem erneuten Startup, der CONTROL_FILES Parameter nochmals angepasst werden
SQL> STARTUP MOUNT
SQL> ALTER SYSTEM SET CONTROL_FILES='+FRA/orcl/controlfile/current.256.711977159',
     '+NEUDATA/orcl/controlfile/current.256.XXXXXX' SCOPE=spfile SID='*'
SQL> SHUTDOWN IMMEDIATE
RMAN> STARTUP MOUNT;
RMAN> RUN {
RMAN> SET NEWNAME FOR DATABASE TO '+NEUDATA';
RMAN> RESTORE DATABASE;
RMAN> SWITCH DATAFILE ALL;
RMAN> SWITCH TEMPFILE ALL;
RMAN> RECOVER DATABASE;
RMAN> }
RMAN> ALTER DATABASE OPEN;

Der Restore der Redolog Members passiert nun natürlich auf die andere ASM Diskgruppe:
SQL> ALTER DATABASE DROP LOGFILE MEMBER '+DATA/orcl/onlinelog/group_1.257.711977165';
...
SQL> ALTER DATABASE ADD LOGFILE MEMBER '+NEUDATA' TO GROUP 1;
...

RMAN> STARTUP NOMOUNT;
RMAN> RESTORE CONTROLFILE FROM '+DATA/orcl/controlfile/current.256.711977159';
RMAN> ALTER DATABASE OPEN;

$ cat initorcl.ora
SPFILE='+DATA/orcl/spfileorcl.ora'
*.db_recovery_file_dest='+FRANEU'

RMAN> STARTUP PFILE=initorcl.ora
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+NEUFRA';
SQL> ALTER SYSTEM SET CONTROL_FILES='+DATA/orcl/controlfile/current.256.711977159','+NEUFRA' SCOPE=spfile SID='*'             
SQL> SHUTDOWN IMMEDIATE;

RMAN> STARTUP MOUNT;
RMAN> RESTORE CONTROLFILE FROM '+DATA/orcl/controlfile/current.256.711977159';
SQL> ALTER SYSTEM SET CONTROL_FILES='+DATA/orcl/controlfile/current.256.711977159',
     '+NEUFRA/orcl/controlfile/current.256.XXXXXX' SCOPE=spfile SID='*'             
SQL> SHUTDOWN IMMEDIATE;
RMAN> STARTUP

Zuletzt die Online Redologs wieder richtig stellen
SQL> ALTER DATABASE DROP LOGFILE MEMBER '+FRA/orcl/onlinelog/group_1.257.711977165';
...
SQL> ALTER DATABASE ADD LOGFILE MEMBER '+NEUFRA' TO GROUP 1;
...

RMAN> STARTUP
LRM-00109: could not open parameter file 'D:\ORACLE\DB\DATABASE\INITORCL.ORA'

RMAN> RESTORE SPFILE FROM AUTOBACKUP RECOVERY AREA 'd:\oracle\fra' DB_NAME 'ORCL';
RMAN> SHUTDOWN IMMEDIATE
RMAN> STARTUP NOMOUNT;
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP DB_NAME 'ORCL';
RMAN> ALTER DATABASE MOUNT;

RMAN> LIST ARCHIVELOG ALL
Key     Thrd Seq     S Low Time
------- ---- ------- - ---------
155     1    51      A 05-MAR-10
        Name: D:\ORACLE\FRANEU\ORCL\ARCHIVELOG\O1_MF_1_51_5S22FOGM_.ARC

156     1    52      A 05-MAR-10
        Name: D:\ORACLE\FRANEU\ORCL\ARCHIVELOG\O1_MF_1_52_5S22FRF5_.ARC

Das Archivelog mit der höchstens Logsequenz +1 ist unser Ziel
RMAN> RESTORE DATABASE UNTIL LOGSEQ 53;
RMAN> RECOVER DATABASE UNTIL LOGSEQ 53;
RMAN> ALTER DATABASE OPEN RESETLOGS;