Auswahl  

 

Oracle
DBA
12.1, 12.2
DBA, Oracle Backup & Recovery
29.06.18
MP
29.06.18
MP

Body

Sind Sie als DBA Ihrer Oracle Datenbank auch für das Backup und Recovery zuständig? Dann standen Sie vielleicht schon einmal vor dem Problem, Ihre Datenbank aufgrund von Benutzer- oder Dateifehlern zurücksetzen zu müssen. Passiert dies einmal, ist das zwar sehr ärgerlich, aber in Verbindung mit dem RMAN noch sehr unkompliziert. Kommen Ihre Entwickler aber häufiger mit dem Wunsch auf Sie zu, die (Entwickler- oder Test-) Datenbank doch noch weiter zurückzusetzen als beim letzten Mal oder den letzten OPEN RESETLOGS ganz ungeschehen zu machen, dann wird das Ganze schon trickreicher und komplizierter.


Im folgenden Artikel werden Ihnen einige mögliche Szenarien vorgestellt, mit denen Sie in diesem Zusammenhang evtl. einmal konfrontiert werden.

Eines noch vorneweg: Diese Szenarien wurden nicht extra für diesen Tipp erfunden und ersponnen, sondern es handelt sich dabei um reale Probleme, mit denen Kunden im Laufe der letzten zehn Jahre Schulungs- und Supporttätigkeit auf uns zugekommen sind.

Zur Ausgangssituation: Die Beispiel-Datenbank wird regelmäßig ONLINE mittels RMAN im NOCATALOG-Modus gesichert. Zielverzeichnis ist die Fast (Flash) Recovery Area, kurz FRA.
 

1. SZENARIO: ZURÜCKSETZEN DER DATENBANK AUF EINEN ÄLTEREN STAND

Um 08:30 kommt einer Ihrer Entwickler mit der Bitte zu Ihnen, den gestrigen Löschvorgang eines Applikationsschemas (HR) rückgängig zu machen. Dazu setzen Sie die Datenbank auf 15:25 des Vortags zurück.

RMAN> SHUTDOWN ABORT
...
RMAN> STARTUP MOUNT
...
RMAN> RUN {
      SET UNTIL TIME "to_date('29.04.2013 15:25:00','dd.mm.yyyy hh24:mi:ss')";
      RESTORE DATABASE;
      RECOVER DATABASE;}
...
RMAN> ALTER DATABASE OPEN RESETLOGS;


Datenbank geöffnet

Damit ist das komplette Schema HR wiederhergestellt. Allerdings sind (verständlicherweise) sämtliche Änderungen, die seit 15:25 durchgeführt worden sind, verloren.
 

2. SZENARIO: ERNEUTES ZURÜCKSETZEN DER DATENBANK AUF EINEN STAND VOR DEM OPEN RESETLOGS

Gegen 09:00 kommt der selbe Entwickler und benötigt in "seiner" Datenbank nun einen Stand von 10:15, der aber zwei Tage zurückliegt. 

Der erste Lösungsansatz, den Sie analog zum Szenario 1 versuchen, wird mit folgendem Fehler quittiert:

...
RMAN> RUN {
      SET UNTIL TIME "to_date('28.04.2013 10:15:00','dd.mm.yyyy hh24:mi:ss')";
      RESTORE DATABASE;
      RECOVER DATABASE;}

Befehl wird ausgeführt: SET UNTIL clause

Starten restore um 30.04.13 09:07:56
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: Fehler bei restore Befehl auf 04/30/2013 09:07:56
RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time

Das Problem liegt darin, dass der gewünschte Zeitpunkt aus einer alten Inkarnation stammt, in die Oracle beim RESTORE/RECOVER nicht automatisch wechseln kann. Die Auflistung der einzelnen Inkarnationen stellt sich wie folgt dar:

RMAN> LIST INCARNATION;

Liste mit Datenbankinkarnationen
DB Schl  Ink Schl DB-Name  DB-ID            STATUS Rücks. SCN  Rücks.zeit
------- ------- -------- ---------------- --- ---------- ----------
1       1       O11G     242551857        PARENT  1          03.11.11 05:39:09
2       2       O11G     242551857        PARENT  994063     02.02.12 10:20:36
3       3       O11G     242551857        PARENT  2524398    25.04.13 09:46:37
4       4       O11G     242551857        CURRENT 2652781    30.04.13 08:45:35

Die aktuelle Inkarnation ist die Nummer 4. Damit der Recovervorgang erfolgreich durchgeführt werden kann, muss zuerst auf die Inkarnation Nummer 3 zurückgesetzt werden. Somit ergibt sich als korrekte Lösung folgendes Vorgehen:

RMAN> SHUTDOWN ABORT
...
RMAN> STARTUP MOUNT
...
RMAN> RESET DATABASE TO INCARNATION 3;

Datenbank auf Version 3 zurückgesetzt

RMAN> LIST INCARNATION;

Liste mit Datenbankinkarnationen
DB Schl  Ink Schl DB-Name  DB-ID            STATUS Rücks. SCN  Rücks.zeit
------- ------- -------- ---------------- --- ---------- ----------
1       1       O11G     242551857        PARENT  1          03.11.11 05:39:09
2       2       O11G     242551857        PARENT  994063     02.02.12 10:20:36
3       3       O11G     242551857        CURRENT 2524398    25.04.13 09:46:37
4       4       O11G     242551857        ORPHAN  2652781    30.04.13 08:45:35

RMAN> RUN {      
      SET UNTIL TIME "to_date('28.04.2013 10:15:00','dd.mm.yyyy hh24:mi:ss')";
      RESTORE DATABASE;
      RECOVER DATABASE;}
...
RMAN> ALTER DATABASE OPEN RESETLOGS;

Datenbank geöffnet

RMAN> LIST INCARNATION;

Liste mit Datenbankinkarnationen
DB Schl  Ink Schl DB-Name  DB-ID            STATUS Rücks. SCN  Rücks.zeit
------- ------- -------- ---------------- --- ---------- ----------
1       1       O11G     242551857        PARENT  1          03.11.11 05:39:09
2       2       O11G     242551857        PARENT  994063     02.02.12 10:20:36
3       3       O11G     242551857        PARENT  2524398    25.04.13 09:46:37
4       4       O11G     242551857        ORPHAN  2652781    30.04.13 08:45:35
5       5       O11G     242551857        CURRENT 2619672    30.04.13 09:24:37

 

3. SZENARIO: NEUTRALISIEREN VON OPEN RESETLOGS VORGÄNGEN

Nachdem Sie auch das zweite Szenario erfolgreich beendet haben und dem Entwickler "seine" Datenbank auf den gewünschten Stand zurückgesetzt haben, kommt um 09:45 der Chef der Entwickler, dessen Arbeit der vergangenen zwei Tage Sie gerade zunichte gemacht haben, und verlangt umgehend die Wiederherstellung der Datenbank vom heutigen Stand 08:30.

Bevor Sie jetzt in Hektik ausbrechen, nehmen Sie zunächst einen (Data Pump) Export der aktuellen Datenbank bzw. einzelner Schemata vor. Damit können Sie am Schluss (hoffentlich) alle Entwickler zufriedenstellen.

Nun geht es darum, alle Spuren der OPEN RESETLOGS Vorgänge zu verwischen. Dazu wird ein altes Controlfile eingespielt, das vor dem ersten RESETLOGS von 08:45 erstellt worden sein muss. Gehen Sie in das Verzeichnis, in das die Backupsets der Controlfiles geschrieben werden (idealerweise das AUTOBACKUP Verzeichnis in der FRA) und verschieben Sie alle aktuelleren Backups in ein temporäres Verzeichnis. Je nach Version von Oracle, müssen Sie evtl. vor dem RESTORE CONTROLFILE noch die DBID setzen (falls notwendig, werden Sie aber dazu aufgefordert).

RMAN> STARTUP NOMOUNT
...
-- Verschieben der aktuellen Backupsets vom Controlfile
-- evtl. RMAN> SET DBID <dbid>
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;

Starten restore um 30.04.13 09:55:16
Zugewiesener Kanal: ORA_DISK_1
Kanal ORA_DISK_1: SID=63 Device-Typ=DISK

Ziel von Recovery-Bereich: /u01/app/oracle/fast_recovery_area
Datenbankname (oder eindeutiger Datenbankname) für Suche benutzt: O11G
Kanal ORA_DISK_1: AUTOBACKUP /u01/app/oracle/fast_recovery_area/O11G/autobackup/2013_04_29/o1_mf_s_814008854_8qw8mpl7_.bkp in Recovery-Bereich gefunden
Suche nach AUTOBACKUP mit Format "%F" nicht versucht, weil DBID nicht festgelegt wurde
Kanal ORA_DISK_1: Kontrolldatei wird aus AUTOBACKUP /u01/app/oracle/fast_recovery_area/O11G/autobackup/2013_04_29/o1_mf_s_814008854_8qw8mpl7_.bkp zurückgeschrieben
Kanal ORA_DISK_1: Zurückschreiben der Kontrolldatei aus AUTOBACKUP abgeschlossen
Ausgabedateiname=/u01/app/oracle/oradata/o11g/control01.ctl
Ausgabedateiname=/u01/app/oracle/fast_recovery_area/O11G/control02.ctl
Beendet restore um 30.04.13 09:55:18

RMAN> ALTER DATABASE MOUNT;

Datenbank angeschlossen

Spätestens jetzt müssen Sie die restlichen Backupsets der Datendateien und der Archivelogs verschieben. Wenn es noch Original-Archivelogs aus den neuen Inkarnationen gibt, müssen auch diese entfernt werden. Wenn Sie daraufhin den RESTORE DATABASE Befehl anstoßen, werden nur die Backups aus der ursprünglichen Inkarnation katalogisiert. Die letzten beiden Inkarnationen sind damit nicht mehr existent.

-- Verschieben der aktuellen Backups inkl. Archivelogs
RMAN> RESTORE DATABASE;

Starten restore um 30.04.13 09:56:30
Starten implicit crosscheck backup um 30.04.13 09:56:30
Zugewiesener Kanal: ORA_DISK_1
Kanal ORA_DISK_1: SID=63 Device-Typ=DISK
7 Objekte auf Übereinstimmung geprüft
Beendet implicit crosscheck backup um 30.04.13 09:56:31

Starten implicit crosscheck copy um 30.04.13 09:56:31
Kanal ORA_DISK_1 wird benutzt
Beendet implicit crosscheck copy um 30.04.13 09:56:31

Suche nach allen Dateien im Recovery-Bereich
Dateien werden katalogisiert...
Katalogisierung erfolgt

Liste mit katalogisierten Dateien
=======================
Dateiname: /u01/app/oracle/fast_recovery_area/O11G/AUTOBACKUP/2013_04_29/O1_MF_S_814008854_8QW8MPL7_.BKP
Dateiname: /u01/app/oracle/fast_recovery_area/O11G/BACKUPSET/2013_04_29/O1_MF_ANNNN_TAG20130429T101534_8QWC16N4_.BKP

Kanal ORA_DISK_1 wird benutzt

Kanal ORA_DISK_1: Zurückschreiben von Datendatei-Backup Set beginnt
Kanal ORA_DISK_1: Datendatei(en) werden zum Wiederherstellen aus Backup Set angegeben
Kanal ORA_DISK_1: Datendatei 00001 wird zu /u01/app/oracle/oradata/o11g/system01.dbf wiederhergestellt
Kanal ORA_DISK_1: Datendatei 00002 wird zu /u01/app/oracle/oradata/o11g/sysaux01.dbf wiederhergestellt
Kanal ORA_DISK_1: Datendatei 00003 wird zu /u01/app/oracle/oradata/o11g/undotbs01.dbf wiederhergestellt
Kanal ORA_DISK_1: Datendatei 00004 wird zu /u01/app/oracle/oradata/o11g/users01.dbf wiederhergestellt
Kanal ORA_DISK_1: Datendatei 00005 wird zu /u01/app/oracle/oradata/o11g/example01.dbf wiederhergestellt
Kanal ORA_DISK_1: Lesen aus Backup Piece /u01/app/oracle/fast_recovery_area/O11G/backupset/2013_04_29/o1_mf_nnndf_tag20130429t093307_8qw8kn1z_.bkp
Kanal ORA_DISK_1: Piece Handle=/u01/app/oracle/fast_recovery_area/O11G/backupset/2013_04_29/o1_mf_nnndf_tag20130429t093307_8qw8kn1z_.bkp Tag=TAG20130429T093307
Kanal ORA_DISK_1: Backup Piece 1 wurde wiederhergestellt
Kanal ORA_DISK_1: Restore abgeschlossen, abgelaufene Zeit: 00:01:05
Beendet restore um 30.04.13 09:57:56

RMAN> RECOVER DATABASE;

Starten recover um 30.04.13 09:58:05
Kanal ORA_DISK_1 wird benutzt

Media Recovery starten

Kanal ORA_DISK_1: Zurückschreiben von Archive Log in Standardziel wird begonnen
Kanal ORA_DISK_1: Archive Log wird zurückgeschrieben
Archive Log Thread=1 Sequence=115
Kanal ORA_DISK_1: Lesen aus Backup Piece /u01/app/oracle/fast_recovery_area/O11G/backupset/2013_04_29/o1_mf_annnn_tag20130429t093413_8qw8mo7k_.bkp
Kanal ORA_DISK_1: Piece Handle=/u01/app/oracle/fast_recovery_area/O11G/backupset/2013_04_29/o1_mf_annnn_tag20130429t093413_8qw8mo7k_.bkp Tag=TAG20130429T093413
Kanal ORA_DISK_1: Backup Piece 1 wurde wiederhergestellt
Kanal ORA_DISK_1: Restore abgeschlossen, abgelaufene Zeit: 00:00:01
Archive Log-Dateiname=/u01/app/oracle/fast_recovery_area/O11G/archivelog/2013_04_30/o1_mf_1_115_8qz4yy1t_.arc Thread=1 Sequence=115
Kanal default: Archive Logs werden gelöscht
Archive Log-Dateiname=/u01/app/oracle/fast_recovery_area/O11G/archivelog/2013_04_30/o1_mf_1_115_8qz4yy1t_.arc RECID=11 STAMP=814103422
Kanal ORA_DISK_1: Zurückschreiben von Archive Log in Standardziel wird begonnen
Kanal ORA_DISK_1: Archive Log wird zurückgeschrieben
Archive Log Thread=1 Sequence=116
...
Kanal ORA_DISK_1: Archive Log wird zurückgeschrieben
Archive Log Thread=1 Sequence=122
Kanal ORA_DISK_1: Lesen aus Backup Piece /u01/app/oracle/fast_recovery_area/O11G/backupset/2013_04_29/o1_mf_annnn_tag20130429t101534_8qwc16n4_.bkp
Kanal ORA_DISK_1: Piece Handle=/u01/app/oracle/fast_recovery_area/O11G/backupset/2013_04_29/o1_mf_annnn_tag20130429t101534_8qwc16n4_.bkp Tag=TAG20130429T101534
Kanal ORA_DISK_1: Backup Piece 1 wurde wiederhergestellt
Kanal ORA_DISK_1: Restore abgeschlossen, abgelaufene Zeit: 00:00:01
Archive Log-Dateiname=/u01/app/oracle/fast_recovery_area/O11G/archivelog/2013_04_30/o1_mf_1_116_8qz4yzfy_.arc Thread=1 Sequence=116
Kanal default: Archive Logs werden gelöscht
...
Archive Log-Dateiname=/u01/app/oracle/fast_recovery_area/O11G/archivelog/2013_04_30/o1_mf_1_122_8qz4yzfh_.arc Thread=1 Sequence=122
Kanal default: Archive Logs werden gelöscht
Archive Log-Dateiname=/u01/app/oracle/fast_recovery_area/O11G/archivelog/2013_04_30/o1_mf_1_122_8qz4yzfh_.arc RECID=18 STAMP=814103423
Media Recovery abgeschlossen, abgelaufene Zeit: 00:00:02
Beendet recover um 30.04.13 09:59:49

RMAN> RECOVER DATABASE;

Starten recover um 30.04.13 09:58:05
Kanal ORA_DISK_1 wird benutzt

Media Recovery starten

Kanal ORA_DISK_1: Zurückschreiben von Archive Log in Standardziel wird begonnen
Kanal ORA_DISK_1: Archive Log wird zurückgeschrieben
Archive Log Thread=1 Sequence=115
Kanal ORA_DISK_1: Lesen aus Backup Piece /u01/app/oracle/fast_recovery_area/O11G/backupset/2013_04_29/o1_mf_annnn_tag20130429t093413_8qw8mo7k_.bkp
Kanal ORA_DISK_1: Piece Handle=/u01/app/oracle/fast_recovery_area/O11G/backupset/2013_04_29/o1_mf_annnn_tag20130429t093413_8qw8mo7k_.bkp Tag=TAG20130429T093413
Kanal ORA_DISK_1: Backup Piece 1 wurde wiederhergestellt
Kanal ORA_DISK_1: Restore abgeschlossen, abgelaufene Zeit: 00:00:01
Archive Log-Dateiname=/u01/app/oracle/fast_recovery_area/O11G/archivelog/2013_04_30/o1_mf_1_115_8qz4yy1t_.arc Thread=1 Sequence=115
Kanal default: Archive Logs werden gelöscht
Archive Log-Dateiname=/u01/app/oracle/fast_recovery_area/O11G/archivelog/2013_04_30/o1_mf_1_115_8qz4yy1t_.arc RECID=11 STAMP=814103422
Kanal ORA_DISK_1: Zurückschreiben von Archive Log in Standardziel wird begonnen
Kanal ORA_DISK_1: Archive Log wird zurückgeschrieben
Archive Log Thread=1 Sequence=116
...
Kanal ORA_DISK_1: Archive Log wird zurückgeschrieben
Archive Log Thread=1 Sequence=122
Kanal ORA_DISK_1: Lesen aus Backup Piece /u01/app/oracle/fast_recovery_area/O11G/backupset/2013_04_29/o1_mf_annnn_tag20130429t101534_8qwc16n4_.bkp
Kanal ORA_DISK_1: Piece Handle=/u01/app/oracle/fast_recovery_area/O11G/backupset/2013_04_29/o1_mf_annnn_tag20130429t101534_8qwc16n4_.bkp Tag=TAG20130429T101534
Kanal ORA_DISK_1: Backup Piece 1 wurde wiederhergestellt
Kanal ORA_DISK_1: Restore abgeschlossen, abgelaufene Zeit: 00:00:01
Archive Log-Dateiname=/u01/app/oracle/fast_recovery_area/O11G/archivelog/2013_04_30/o1_mf_1_116_8qz4yzfy_.arc Thread=1 Sequence=116
Kanal default: Archive Logs werden gelöscht
...
Archive Log-Dateiname=/u01/app/oracle/fast_recovery_area/O11G/archivelog/2013_04_30/o1_mf_1_122_8qz4yzfh_.arc Thread=1 Sequence=122
Kanal default: Archive Logs werden gelöscht
Archive Log-Dateiname=/u01/app/oracle/fast_recovery_area/O11G/archivelog/2013_04_30/o1_mf_1_122_8qz4yzfh_.arc RECID=18 STAMP=814103423
Media Recovery abgeschlossen, abgelaufene Zeit: 00:00:02
Beendet recover um 30.04.13 09:59:49

RMAN> ALTER DATABASE OPEN RESTLOGS;

Datenbank geöffnet

RMAN> LIST INCARNATION;

Liste mit Datenbankinkarnationen
DB Schl  Ink Schl DB-Name  DB-ID            STATUS Rücks. SCN  Rücks.zeit
------- ------- -------- ---------------- --- ---------- ----------
1       1       O11G     242551857        PARENT  1          03.11.11 05:39:09
2       2       O11G     242551857        PARENT  994063     02.02.12 10:20:36
3       3       O11G     242551857        PARENT  2524398    25.04.13 09:46:37
4       4       O11G     242551857        CURRENT 2653817    30.04.13 10:01:13

Somit haben Sie die Datenbank wieder auf den Stand von 08:30 gebracht. Die beiden zuvor durchgeführten OPEN RESETLOGS Szenarien sind auf diese Weise vollständig neutralisiert worden. Jetzt können Sie noch einen (Data Pump) Import der gewünschten Schemata durchführen ... und alle sind zufrieden.

FAZIT

Solange Sie die notwendigen Backups und Archivelogs zur Verfügung haben, können Sie jeden beliebigen (alten) Stand Ihrer Datenbank erreichen. Und falls es die Notwendigkeit gibt, zwischen Inkarnationen zu wechseln, ist auch dies möglich.

Die vorgestellten Szenarien beziehen sich in der Regel auf Entwickler- bzw. Test-Datenbanken, bei denen Sie im Stand beliebig hin- und herspringen. Bei produktiven Systemen wird dies vermutlich eher selten der Fall sein.

Interesse an weiteren Crashszenarien und wie sie gelöst werden können? Dann besuchen Sie einfach unseren RMAN Backup & Recovery Kurs.