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.

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:

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:

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:

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).

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.