Restore und Recovery mit RMAN

Führt dich im Störfall Schritt für Schritt durch die richtige RMAN-Wiederherstellung: 19 Szenarien — Verlust von Datendatei, SYSTEM/UNDO, Tempfile, beschädigtem Block, Online-Redo-Log, Controlfile und spfile; vollständiger Restore, Restore in ein anderes Verzeichnis/nach ASM und auf einen anderen Server; Point-in-Time-Recovery (CDB oder PDB-PITR), Flashback Database, Tablespace-PITR, Wiederherstellung einer einzelnen Tabelle (RECOVER TABLE), gelöschte PDB; Restore über das Netz von Data Guard (FROM SERVICE), Restore nur von Archive Logs, Bekanntmachen verschobener Backups (CATALOG) und ein Probelauf, der keine Daten schreibt (PREVIEW/VALIDATE). Jedes Szenario folgt der Reihenfolge Diagnose → Sicherheitsnetz → Durchführung → Verifikation → neues Backup; für Single Instance, Oracle Restart und RAC (Wiederherstellung auf einer Instanz mit CLUSTER_DATABASE=FALSE) gibt es eigene Schritte. Es geht um die Wiederherstellung, nicht um das Erstellen von Backups; für den Backup-Plan siehe den Guide „Oracle-Backup-Strategie“.

Topologie: 1 Server (Single Instance oder Oracle Restart) oder RAC; im Szenario mit neuem Host Quelle + Ziel

Szenarien

• Probelauf: RESTORE … PREVIEW / VALIDATE (ändert nichts) — Nichts ist kaputt; du willst ohne Schreiben von Daten sehen, ob die Backups für eine Wiederherstellung wirklich ausreichen (die Datenbank bleibt geöffnet). Auch der erste Schritt für die monatliche Restore-Übung und wenn du unsicher bist, welches Szenario du wählen sollst.
• Backups in ein anderes Verzeichnis verschoben / RMAN findet kein Backup (CATALOG) — Die Backup Pieces sind vorhanden, aber RMAN kennt sie nicht (verschoben, NFS geändert, von einem anderen Server kopiert): Du bekommst RMAN-06023/06025. Die Datenbank bleibt geöffnet.
• Nur Archive Logs wiederherstellen (RESTORE ARCHIVELOG) — Für LogMiner, eine Standby-Lücke oder manuelles Recovery werden die Archive Logs eines bestimmten Sequence-Bereichs auf der Platte gebraucht; die Datenbank bleibt geöffnet, keine Datei wird überschrieben.
• Verlust/Beschädigung einer einzelnen Datendatei oder eines Tablespace (Datenbank bleibt geöffnet) — Die Datenbank ist geöffnet, nur eine Datendatei oder ein Tablespace ist nicht lesbar (ORA-01157/01110/01116); alles andere läuft. Gehört die Datei zu SYSTEM/UNDO, wähle die Karte „SYSTEM oder UNDO“, ist es ein Tempfile, die Karte „Tempfile“, und lässt sich die Datei öffnen, aber einige Blöcke sind beschädigt (ORA-01578), die Karte „Beschädigter Block“.
• Beschädigter Block vorhanden (ORA-01578, Block Media Recovery) — Eine Abfrage liefert ORA-01578/ORA-26040, das Backup bricht mit ORA-19566 ab oder VALIDATE hat beschädigte Blöcke gefunden; der Rest der Datei ist intakt. Die Datenbank bleibt geöffnet, nur die beschädigten Blöcke werden repariert (Enterprise Edition; unter SE2 wird die Datei wiederhergestellt). Lässt sich die ganze Datei nicht öffnen (ORA-01157), nimm die Karte „Einzelne Datendatei“.
• SYSTEM- oder UNDO-Datendatei verloren (Datenbank lässt sich nicht öffnen) — Die verlorene oder beschädigte Datei gehört zum SYSTEM- oder UNDO-Tablespace: Sie kann nicht offline gesetzt werden, die Datenbank (bei einer PDB-Datei nur diese PDB) wird heruntergefahren und im MOUNT-Zustand wiederhergestellt. Es gehen keine Daten verloren. Gehört die Datei zu einem anderen Tablespace, löst die Karte „Einzelne Datendatei“ das Problem, ohne die Datenbank herunterzufahren.
• Tempfile verloren oder beschädigt (TEMP-Tablespace) — Sortier-/Hash-Operationen liefern ORA-01157/ORA-01187/ORA-25153, und die Datei ist ein Tempfile (die Nummer in der Fehlermeldung ist größer als der Wert von db_files, z. B. data file 201). Ein Restore ist nicht nötig; es wird ein neues Tempfile hinzugefügt, die Datenbank bleibt geöffnet.
• Online-Redo-Log verloren oder beschädigt — Im Alert Log steht ORA-00313/00312 (kann nicht geöffnet werden) oder ORA-00327/00366/00367 (beschädigt). Fehlt nur ein Member oder ist die Gruppe INACTIVE, bleibt die Datenbank geöffnet; ist die CURRENT-Gruppe verloren, sind Restore + RESETLOGS nötig und die letzten Transaktionen gehen verloren. Den Status der Gruppe zeigt der Diagnoseschritt; triff deine Auswahl danach.
• Alle Controlfile-Kopien verloren — Die Instanz findet im MOUNT-Schritt kein Controlfile oder kann es nicht lesen (ORA-00205/00202/00210); Datendateien und Redo sind intakt. Ist eine der Kopien intakt, ist kein Restore nötig (das zeigt der Diagnoseschritt); sind alle verloren, wird aus dem Autobackup wiederhergestellt und mit RESETLOGS geöffnet. Da das Online-Redo intakt ist, gehen keine Daten verloren.
• spfile verloren — Das spfile wurde gelöscht oder ist beschädigt; die Instanz startet nicht (ORA-01078/LRM-00109) oder läuft, aber die Datei fehlt. Datendateien werden nicht angefasst, es gehen keine Daten verloren; läuft die Instanz noch, gibt es auch keine Downtime.
• Vollständiger Restore, gleicher Server (Datendateien verloren; Controlfile und Redo intakt) — Alle oder die meisten Datendateien sind weg, Controlfile und Online-Redo-Logs sind intakt; die Datenbank wird heruntergefahren, es gehen keine Daten verloren. Ist die alte Platte bzw. das alte Verzeichnis der Dateien nicht mehr nutzbar, wähle die Karte „in ein anderes Verzeichnis“, ist auch das Controlfile verloren, zuerst die Karte „Controlfile“, und ist der Server komplett weg, die Karte „Restore auf einen anderen Server“.
• Platte weg: Datenbank in ein anderes Verzeichnis / nach ASM wiederherstellen (SET NEWNAME) — Die Platte oder Diskgruppe mit den Datendateien ist nicht nutzbar; Controlfile und Redo sind intakt. Die Dateien werden in ein neues Verzeichnis oder eine ASM-Diskgruppe wiederhergestellt, die Datenbank wird heruntergefahren, es gehen keine Daten verloren.
• Rückkehr zu Zeitpunkt / SCN (PITR, RESETLOGS) — Falsches DELETE/UPDATE/TRUNCATE oder fehlerhafte Anwendungsversion: Setzt die Datenbank (oder nur die PDB) auf einen früheren Zeitpunkt zurück; alle Änderungen danach gehen verloren (RESETLOGS). Prüfe zuerst die engeren Wege: einzelne Tabelle → „Einzelne Tabelle wiederherstellen“, einzelner Tablespace → TSPITR, Flashback aktiv → „Flashback Database“ (kein Restore, viel schneller).
• Mit Flashback Database zurücksetzen (Restore Point / SCN / Zeit) — Flashback ist aktiv oder es gibt einen Guaranteed Restore Point, und keine Datei fehlt: Ohne Restore wird die Datenbank innerhalb von Minuten zurückgesetzt (Enterprise Edition). RESETLOGS ist erforderlich. Aktiv?: SELECT flashback_on FROM v$database; → YES oder eine Zeile mit GUARANTEE_FLASHBACK_DATABASE = YES in v$restore_point.
• Einen Tablespace auf einen früheren Zeitpunkt zurücksetzen (TSPITR) — Die fehlerhafte Operation betraf nur Objekte in einem Tablespace; der Rest der Datenbank soll auf dem aktuellen Stand bleiben (Enterprise Edition). Der Tablespace ist während des Vorgangs offline, und alle Objekte darin werden auf den Zielzeitpunkt zurückgesetzt; sind nur ein, zwei Tabellen betroffen, setzt „Einzelne Tabelle wiederherstellen“ weniger zurück.
• Einzelne Tabelle wiederherstellen (RECOVER TABLE, ab 12c Enterprise Edition) — Eine einzelne Tabelle wurde versehentlich gelöscht oder beschädigt; der Rest der Datenbank soll unverändert bleiben (ab 12c Enterprise Edition). Wurde sie mit DROP gelöscht und kein PURGE ausgeführt, prüfe zuerst den Recycle Bin: FLASHBACK TABLE … TO BEFORE DROP dauert Sekunden (der Diagnoseschritt zeigt es).
• Gelöschte PDB zurückholen (DROP PLUGGABLE DATABASE) — Eine PDB wurde mit DROP PLUGGABLE DATABASE gelöscht. Sind die Dateien noch vorhanden, wird sie per XML wieder eingehängt; wurden sie gelöscht, wird sie aus dem Backup geholt (ab 21c ein einziger Befehl, unter 19c über eine temporäre CDB). Die CDB bleibt geöffnet.
• Restore auf einen anderen Server (neuer Host, aus Controlfile-Autobackup) — Der Server ist komplett weg oder es soll eine Kopie/Testumgebung aufgebaut werden: Das Backup wird auf einem anderen Server wiederhergestellt (nur Single Instance, Dateisystem). Wiederhergestellt wird bis zum letzten gesicherten Archive Log, alles danach geht verloren; die Kopie wird mit RESETLOGS geöffnet.
• Data Guard: Datei über das Netz vom Standby/Primary holen (FROM SERVICE) — Data Guard ist vorhanden: Du holst eine auf dem Primary verlorene Datendatei vom Standby bzw. einen zurückliegenden Standby oder ein verlorenes Standby-Controlfile vom Primary, ohne Backup Pieces zu verwenden (ab 12c).

Vor dem Start

• Der Vorfall ist dokumentiert und das Anwendungsteam informiert: wann, was passiert ist, welche Fehlermeldung. Falls möglich, wurde vor Beginn der Wiederherstellung eine Kopie des aktuellen Zustands erstellt (Server-/Platten-Snapshot oder zumindest eine Kopie der verbliebenen Datendateien, des Controlfiles und der Online-Redo-Logs); ein falscher Schritt kann die Lage noch verschlimmern.
• Die Backups sind erreichbar: …… und für die Archive Logs die FRA …… sind eingehängt und lesbar. Liegen die Backups auf Band/MML, laufen der SBT-Kanal und der Software-Agent.
• Die DBID ist bekannt (…). Falls nicht: die Zeile connected to target database: … (DBID=…) in alten RMAN-Logs… oder der Dateiname des Autobackups (…_cf_c-<DBID>-<YYYYMMDD>-<nn>)….
• Das Auxiliary-Verzeichnis … existiert und hat so viel freien Platz wie SYSTEM + SYSAUX + UNDO + der Tablespace der Tabelle; der Server hat ~2 GB freien RAM für die temporäre Instanz.
• …RECOVER TABLE („Recovering tables and table partitions from RMAN backups“) ist ein Feature der Enterprise Edition.…In Standard Edition 2 gibt es kein RECOVER TABLE: Statt der folgenden Schritte stellst du das Backup auf einem anderen Server wieder her („Restore auf einen anderen Server“ + PITR) und holst die Tabelle mit Data Pump.…
• Auf dem Zielserver ist dieselbe Oracle-Version mit demselben RU-Stand als reine Software installiert (opatch lspatches auf beiden Seiten gleich), oracle-Benutzer/-Gruppen und Verzeichnisstruktur entsprechen der Quelle, genug Plattenplatz ist vorhanden. Auf dem Ziel läuft keine Datenbank mit demselben Namen.
• Das Wartungs-/Downtime-Fenster ist genehmigt… (in diesem Szenario bleibt die Datenbank geöffnet; nur die betroffenen Objekte sind beeinträchtigt)…. Der Backup-Scheduler (cron/systemd/Scheduler) ist bis zum Ende der Wiederherstellung angehalten; sonst könnte mitten im Vorgang ein Backup oder DELETE OBSOLETE laufen.
• Der Eintrag in der Clusterware ist bekannt: Ort von spfile und Passwortdatei, …Instanzen und Knoten…Status der Datenbank… (srvctl config database -db …). Sichere diese Ausgabe vor der Wiederherstellung.
• …Block Media Recovery…Tablespace Point-in-Time Recovery…Flashback Database… ist ein Feature der Enterprise Edition; in Standard Edition 2 funktioniert der Befehl nicht. Der SE2-Weg dieses Szenarios wird in den Schritten gesondert gezeigt.
• Für die temporäre (Auxiliary-)Instanz ist im Verzeichnis …………… so viel freier Platz wie SYSTEM + SYSAUX + UNDO… + …… + PDB… vorhanden, und der Server hat mindestens so viel freien Speicher wie das sga_target des Ziels (RMAN gibt der temporären Instanz standardmäßig dieselbe SGA).
• Data Guard ist bereit: Die Passwortdatei ist auf beiden Seiten gleich (gleiches SYS- oder SYSBACKUP-Passwort), die tnsnames.ora dieses Servers enthält die Einträge … und …, COMPATIBLE ≥ 12.0. FROM SERVICE funktioniert nicht mit Betriebssystem-Authentifizierung (rman target /); RMAN verbindet sich mit Passwort.
• Für Flashback Database ist eine FRA definiert, und entweder ist Flashback Logging aktiv (FLASHBACK_ON = YES) oder der Zielzeitpunkt ist ein Guaranteed Restore Point. Keine Datendatei ist verloren/beschädigt (Flashback holt keine verlorene Datei zurück), und nach dem Zielzeitpunkt wurde keine Datendatei verkleinert (shrink) und kein Controlfile neu erstellt.

Phasen der Anleitung

• Bestandsaufnahme — Zustand ermitteln · Zustand ermitteln · Recycle Bin prüfen (bei DROP ist vielleicht kein Backup nötig) · Zielzeitpunkt festlegen
• Ist das nötige Backup vorhanden? — Instanz im MOUNT-Modus starten · Instanz im MOUNT-Modus starten (srvctl) · Backups auflisten · Autobackup-Dateien finden · Wiederherstellung voranzeigen (PREVIEW) · Backup Pieces lesen und prüfen (VALIDATE) …
• Datendatei/Tablespace wiederherstellen (online) — … offline setzen · … wiederherstellen und recovern · … online setzen
• Vollständiger Restore (gleicher Server) — Datenbank wiederherstellen, recovern und öffnen · …In den Cluster-Modus zurückkehren und die Datenbank über die Clusterware starten…Datenbank über die Clusterware (Oracle Restart) neu starten…
• Rückkehr zu Zeitpunkt / SCN (PITR) — Aktuellen Zustand vor der Rückkehr sichern · Datenbank als einzelne Instanz in MOUNT bringen (srvctl) · …PDB…Datenbank… auf den Zielzeitpunkt zurücksetzen · …In den Cluster-Modus zurückkehren und die Datenbank über die Clusterware starten…Datenbank über die Clusterware (Oracle Restart) neu starten…
• Einzelne Tabelle wiederherstellen (RECOVER TABLE) — Auxiliary-Verzeichnis vorbereiten · Tabelle vom Zielzeitpunkt wiederherstellen · Zurückgeholte Daten vergleichen
• Controlfile wiederherstellen — Prüfen, ob noch eine Controlfile-Kopie vorhanden ist · Prüfen, ob noch eine Controlfile-Kopie vorhanden ist (ASM) · Instanz in NOMOUNT starten (srvctl) · Controlfile aus dem Autobackup wiederherstellen und öffnen · …In den Cluster-Modus zurückkehren und die Datenbank über die Clusterware starten…Datenbank über die Clusterware (Oracle Restart) neu starten…
• spfile wiederherstellen — spfile aus den Parametern im Speicher neu schreiben · spfile aus den Parametern im Speicher nach ASM schreiben · spfile aus dem Autobackup wiederherstellen · spfile aus dem Autobackup nach ASM wiederherstellen · Prüfen, dass die Instanz mit spfile gestartet ist
• Quellserver: Informationen sammeln und Backups übertragen — Aktuelles Backup erstellen · DBID, Autobackup und Verzeichnisliste schreiben · Backups und Passwortdatei zum Ziel kopieren
• Zielserver: Restore und Recovery — Verzeichnisse anlegen · oratab-Eintrag hinzufügen · spfile und Controlfile wiederherstellen, MOUNT · Backup Pieces bekannt machen (CATALOG) · Wiederherstellen, bis zum letzten Archive Log recovern und öffnen · Kopie von der Quelle trennen (optional)
• Diagnose: Warum findet RMAN das Backup nicht? — Neuen Ort der Backup Pieces ansehen · Bekannte und fehlende Backups von RMAN auflisten
• Sicherheitsnetz — Aktuellen Stand des Controlfiles kopieren
• Backups bei RMAN bekannt machen — Pieces im neuen Verzeichnis bekannt machen (CATALOG START WITH) · Einträge des alten Orts bereinigen
• Verifikation: Werden die Backups jetzt gefunden? — Wiederherstellung erneut voranzeigen · Backup-Skript an den neuen Ort anpassen
• Diagnose: Welche Archive Logs werden gebraucht, und sind sie im Backup? — Prüfen, ob die Archive Logs auf der Platte liegen · Backup der Archive Logs finden und voranzeigen
• Sicherheitsnetz: Zielverzeichnis und Platz — Restore-Verzeichnis vorbereiten
• Archive Logs wiederherstellen — Archive Logs wiederherstellen (RESTORE ARCHIVELOG)
• Verifikation und Aufräumen — Wiederhergestellte Archive Logs auflisten · Wiederhergestellte Archive Logs nach Abschluss löschen
• Diagnose: Ist es ein beschädigter Block? — Datei prüfen (VALIDATE) · Beschädigte Blöcke und zugehöriges Objekt auflisten
• Sicherheitsnetz: Gibt es eine intakte Kopie und eine Archivkette? — Backups der Datei und Wiederherstellungskette voranzeigen
• Beschädigte Blöcke reparieren — Beschädigte Blöcke aus dem Backup reparieren (RECOVER CORRUPTION LIST) · Standard Edition 2: Datendatei wiederherstellen · NOLOGGING-Blöcke korrigieren (falls vorhanden)
• Verifikation: Sind die Blöcke intakt? — Datei erneut prüfen · Ursache suchen: Platten- und Storage-Fehler
• Diagnose: Ist die Datei SYSTEM oder UNDO? — Instanz im MOUNT-Modus starten · Instanz im MOUNT-Modus starten (srvctl) · Prüfen, dass die Datei zu SYSTEM oder UNDO gehört · Nötiges Backup voranzeigen und prüfen
• Sicherheitsnetz — Aktuellen Stand des Controlfiles kopieren
• SYSTEM-/UNDO-Datendatei wiederherstellen — PDB schließen · Datendatei wiederherstellen, recovern und öffnen · …In den Cluster-Modus zurückkehren und die Datenbank über die Clusterware starten…Datenbank über die Clusterware (Oracle Restart) neu starten…
• Diagnose: Ist die verlorene Datei ein Tempfile? — Tempfiles und ihren Status ansehen · Datei und Alert Log prüfen
• Sicherheitsnetz: Platzprüfung — Prüfen, ob Platz für das neue Tempfile ist
• Neues Tempfile hinzufügen, verlorenes entfernen — Neues Tempfile hinzufügen und verlorenes entfernen
• Verifikation — Temp-Tablespace prüfen
• Diagnose: Welche Gruppe, in welchem Zustand? — Status der Redo-Log-Gruppen ansehen