RMAN Recover Szenarien inkl. Wechsel der Inkarnation

Transkript

1 Tipps & Tricks: Mai 2013 Bereich: DBA, B&R, RMAN Erstellung: 05/2013 MM Versionsinfo: 10.2 bis 11.2 Letzte Überarbeitung: 05/2013 MM Als PDF Downloaden! RMAN Recover Szenarien inkl. Wechsel der Inkarnation 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(' :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. Allerdings sind (verständlicherweise) sämtliche Änderungen, die seit 15:25 durchgeführt worden sind, verloren. MuniQSoft GmbH, Grünwalder Weg 13a, Unterhaching, Tel. 089 / Seite 1 von 7

2 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(' :15:00','dd.mm.yyyy hh24:mi:ss')"; RESTORE DATABASE; RECOVER DATABASE;} Befehl wird ausgeführt: SET UNTIL clause Starten restore um :07:56 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: Fehler bei restore Befehl auf 04/30/ :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: 1 1 O11G PARENT :39: O11G PARENT :46: O11G CURRENT :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 MuniQSoft GmbH, Grünwalder Weg 13a, Unterhaching, Tel. 089 / Seite 2 von 7

3 1 1 O11G PARENT :39: O11G CURRENT :46: O11G ORPHAN :45:35 RMAN> RUN { SET UNTIL TIME "to_date(' :15:00','dd.mm.yyyy hh24:mi:ss')"; RESTORE DATABASE; RECOVER DATABASE;} RMAN> ALTER DATABASE OPEN RESETLOGS; Datenbank geöffnet 1 1 O11G PARENT :39: O11G PARENT :46: O11G ORPHAN :45: O11G CURRENT :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 :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 MuniQSoft GmbH, Grünwalder Weg 13a, Unterhaching, Tel. 089 / Seite 3 von 7

4 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_ _8qw8mpl7_ 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_ _8qw8mpl7_ 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 :55:18 RMAN> ALTER DATABASE MOUNT; Datenbank angeschlossen Spätestens jetzt müssen Sie die restlichen Backupsets der Datendateien und der logs verschieben. Wenn es noch Original-logs 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. logs RMAN> RESTORE DATABASE; Starten restore um :56:30 Starten implicit crosscheck backup um :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 :56:31 Starten implicit crosscheck copy um :56:31 Beendet implicit crosscheck copy um :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_ _8qw8mpl7_ Dateiname: /u01/app/oracle/fast_recovery_area/o11g/backupset/2013_04_29/o1_mf_annnn_tag t1015 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 wird zu /u01/app/oracle/oradata/o11g/system01.dbf Kanal ORA_DISK_1: Datendatei wird zu /u01/app/oracle/oradata/o11g/sysaux01.dbf MuniQSoft GmbH, Grünwalder Weg 13a, Unterhaching, Tel. 089 / Seite 4 von 7

5 Kanal ORA_DISK_1: Datendatei wird zu /u01/app/oracle/oradata/o11g/undotbs01.dbf Kanal ORA_DISK_1: Datendatei wird zu /u01/app/oracle/oradata/o11g/users01.dbf Kanal ORA_DISK_1: Datendatei wird zu /u01/app/oracle/oradata/o11g/example01.dbf /u01/app/oracle/fast_recovery_area/o11g/backupset/2013_04_29/o1_mf_nnndf_tag t0933 Handle=/u01/app/oracle/fast_recovery_area/O11G/backupset/2013_04_29/o1_mf_nnndf_tag Tag=TAG T Kanal ORA_DISK_1: Restore abgeschlossen, abgelaufene Zeit: 00:01:05 Beendet restore um :57:56 RMAN> RECOVER DATABASE; Starten recover um :58:05 Media Recovery starten Kanal ORA_DISK_1: Zurückschreiben von Log in Standardziel wird begonnen Kanal ORA_DISK_1: Log wird zurückgeschrieben Log Thread=1 Sequence=115 /u01/app/oracle/fast_recovery_area/o11g/backupset/2013_04_29/o1_mf_annnn_tag t0934 Tag=TAG T Thread=1 Sequence=115 Kanal default: Logs werden gelöscht RECID=11 STAMP= Kanal ORA_DISK_1: Zurückschreiben von Log in Standardziel wird begonnen Kanal ORA_DISK_1: Log wird zurückgeschrieben Log Thread=1 Sequence=116 Kanal ORA_DISK_1: Log wird zurückgeschrieben Log Thread=1 Sequence=122 /u01/app/oracle/fast_recovery_area/o11g/backupset/2013_04_29/o1_mf_annnn_tag t1015 Tag=TAG T Log-Dateiname=/u01/app/oracle/fast_recovery_area/O11G/archivelog/2013_04_30/o1_mf_1_116_8 MuniQSoft GmbH, Grünwalder Weg 13a, Unterhaching, Tel. 089 / Seite 5 von 7

6 Log-Dateiname=/u01/app/oracle/fast_recovery_area/O11G/archivelog/2013_04_30/o1_mf_1_116_8 Thread=1 Sequence=116 Kanal default: Logs werden gelöscht Thread=1 Sequence=122 Kanal default: Logs werden gelöscht RECID=18 STAMP= Media Recovery abgeschlossen, abgelaufene Zeit: 00:00:02 Beendet recover um :59:49 RMAN> RECOVER DATABASE; Starten recover um :58:05 Media Recovery starten Kanal ORA_DISK_1: Zurückschreiben von Log in Standardziel wird begonnen Kanal ORA_DISK_1: Log wird zurückgeschrieben Log Thread=1 Sequence=115 /u01/app/oracle/fast_recovery_area/o11g/backupset/2013_04_29/o1_mf_annnn_tag t0934 Tag=TAG T Thread=1 Sequence=115 Kanal default: Logs werden gelöscht RECID=11 STAMP= Kanal ORA_DISK_1: Zurückschreiben von Log in Standardziel wird begonnen Kanal ORA_DISK_1: Log wird zurückgeschrieben Log Thread=1 Sequence=116 Kanal ORA_DISK_1: Log wird zurückgeschrieben Log Thread=1 Sequence=122 /u01/app/oracle/fast_recovery_area/o11g/backupset/2013_04_29/o1_mf_annnn_tag t1015 Tag=TAG T Log-Dateiname=/u01/app/oracle/fast_recovery_area/O11G/archivelog/2013_04_30/o1_mf_1_116_8 Thread=1 Sequence=116 Kanal default: Logs werden gelöscht MuniQSoft GmbH, Grünwalder Weg 13a, Unterhaching, Tel. 089 / Seite 6 von 7

7 Thread=1 Sequence=122 Kanal default: Logs werden gelöscht RECID=18 STAMP= Media Recovery abgeschlossen, abgelaufene Zeit: 00:00:02 Beendet recover um :59:49 RMAN> ALTER DATABASE OPEN RESTLOGS; Datenbank geöffnet 1 1 O11G PARENT :39: O11G PARENT :46: O11G CURRENT :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 logs 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 einen unserer Backup & Recovery oder RMAN-Kurse. MuniQSoft GmbH, Grünwalder Weg 13a, Unterhaching, Tel. 089 / Seite 7 von 7