RMAN Wiederherstellung

1. Allgemeines

Es gibt einige Verweise auf die Backup Seite, nach welcher das Backup schon vorher erstellt werden muss.

1.1. Überblick

Die notwendigen Schritte seien hier kurz zusammengefasst:

1. Voraussetzungen sicherstellen
2. Pfile anpassen
3. Restore Controlfile
4. Set DBID
5. SCN suchen
6. Restore und Recover
7. Wiederherstellen beenden

Wobei die Schritte 2 bis 4 ausgelassen werden können, wenn das Restore auf der selben DB stattfindet, von der das Backup stammt. Nach 1 werden die Schritte in dieser Anleitung trotzdem fundamental getrennt (Kapitel 3 oder 4).

1.2. Nutzung RMAN

Es gibt verschiedene Möglichkeiten, RMAN zu starten, folgende ist zu empfehlen (<passwort> durch das Passwort ersetzen):

Standardmäßig öffnet RMAN eine interaktive Session (in der keine Pfeiltasten genutzt werden können!), das Beenden ist mit EOF (Strg+D) möglich. Jeder Befehl muss mit einem Semikolon abgeschlossen werden. Befehle werden standardmäßig sofort ausgeführt, Ausnahme ist ein Run-Block (Befehle innerhalb run{}), dessen Befehle erst mit der schließenden Klammer ausgeführt werden. Siehe auch Backup Seite.

1.3. Container

• Im durchgespielten Szenario waren beide DBs (Quelle und Ziel) in Docker Containern
• Deswegen ist hier auch immer notiert, wo der Schritt ggf. ausgeführt werden muss
• Dabei ist der Pfad /opt/oracle/oradata/ des Containers nach /srv/oracle-db-12c/data/ außerhalb des Containers gemountet

1.4. Backup

Zur Informaiton; die Verzeichnisstruktur in der "Fast Recovery Area" (FRA) sieht wie folgt aus (mit Komentaren rechts):

Das Pfile ist nicht standardmäßig enthalten, wird aber für die Disaster Recovery auf einem anderen Host (/Container/DBMS) benötigt.

2. Vorbereitung und Voraussetzungen

2.1. Konsolen

Um effizient arbeiten zu können, empfiehlt es sich, drei oder vier Konsolen zu verwenden:

1. Auf der Quelldatenbank, oder wo auch immer das Backup liegt
2. Auf der Zieldatenbank, mit RMAN geöffnet
   1. RMAN nicht beenden, damit die temporären Schritte nicht rückgängig gemacht werden
   2. Die Befehle sind hier immer mit RMAN> angegeben, müssen aber natürlich ohne dieses RMAN> eingegeben werden

3. Auf der Zieldatenbank mit einer Root Shell (sowohl innerhalb als auch außerhalb des Containers)

   docker exec -it oracle-db-12c_database_1 bash # in der Console kann RMAN genutzt werden   rman target '"sys/<passwort> as sysdba"' # <passwort> siehe docker-compose.yml

4. Ggf. aus der (3) zwei Shells machen, eine innerhalb und eine außerhalb des Containers, falls das hin- und herspringen verwirrt

2.2. Konfiguration

Die Zieldatenbank sollte die gleiche Konfiguration wie die Quelldatenbank haben, siehe Backup Seite. Insbesondere muss das Autobackup eingeschaltet sein.

2.3. Archivelog

Theoretisch vielleicht nicht unbedingt notwendig. Aber es ist zu empfehlen, die DB in den Archivelog Mode zu bringen - sonst können auch keine Online Backups angelegt werden.

2.4. Backup Daten in die Ziel-FRA kopieren

1. Backup von Quelldatenbank finden/besorgen
   • Das Backup liegt nach Anleitung der Backup Seite in der "Fast Recovery Area" (FRA) unter /opt/oracle/oradata/fast_recovery_area/ (ggf. im Container)
   • Struktur siehe 1.4.

   • Es wird ein Autobackup, alle Backupsets eines Tages, und ein Pfile benötigt - am besten gleich die komplette FRA kopieren (Nutzer, Host und Zielverzeichnis abändern):

     Backup zum Zielhost kopieren

     scp -r fast_recovery_area/ [email protected]:/home/yourlinuxuser/

2. Backup an den richtigen Ort kopieren, zum Beispiel, wenn /srv/oracle-db-12c/data/ auf den Ordner /opt/oracle/oradata/ im Container gemountet ist (Quellverzeichnis abändern, außerhalb des Containers):

   FRA Backup kopieren

   cp -r /home/yourlinuxuser/fast_recovery_area/ /srv/oracle-db-12c/data/

   Jedenfalls muss das Backup in die FRA unter oradata der Zieldatenbank kopiert werden (hier im Beispiel ist das data Verzeichnis unter oradata des Containers gemountet)

3. Es müssen noch die Rechte angepasst werden (innerhalb des Containers)

   
   

   Dafür werden Superuser-Rechte innerhalb des Containers benötigt! Nach dem Einloggen in den Container (siehe 2.1) muss noch "su" ausgeführt werden.
   Das Passwort dafür ist im KeePass zu finden. ← ist es nicht!

   Die Berechtigungen können aber auch außerhalb von Docker angepasst werden.

   
   

   chown -R 3011:1002 /srv/oracle-db-12c-data/fast_recovery_area/

   
   

   FRA Berechtigungen anpassen

   bash-4.2# cd /opt/oracle/oradata/ bash-4.2# chown -R oracle:oinstall fast_recovery_area/

Die Codeschnipsel sind nur Beispiele, viele Wege führen nach Rom. Nur auf keinen Fall das Ändern der Rechte vergessen.

3. Recovery lokal

Falls das Restore auf der selben Maschine durchgeführt wird wie die Recovery, so ist einiges einfacher.

Zuerst die DB in den Nomount state bringen und die vorhandenen Backups anzeigen lassen:

Ein Backup (Low SCN, letzte Low SCN ist das neuste Backup) aussuchen, und zum Beispiel wie folgt wiederherstellen:

Anschließend die DB wieder öffnen, und dabei die Archivelogs zurücksetzen:

4. Recovery auf anderer Maschine (Disaster Recovery)

Im schlimmsten Fall ist es nötig, die DB auf einer anderen Maschine wiederherzustellen. Das ist etwas aufwändiger.

4.1. Pfile

Das Pfile liegt unter /opt/oracle/oradata/fast_recovery_area/ im Container, muss aber wahrscheinlich von außerhalb des Containers angepasst werden (z.B. /srv/oracle-db-12c/data/fast_recovery_area/).

Es sind zwei Arten von Anpassungen am Pfile nötig:

1. Anpassungen, die nötig sind, weil Quell- und Zieldatenbank sich unterschieden
   • Diese werden anschließend auch nicht rückgängig gemacht
   • Es geht vor allem um zwei Parameter: memory_target und memory_target_max
     • memory_target muss auf weniger (ca. 10%) als die Größe des von der Oracle DB verwendeten Tempfs gesetzt werden, in Byte, min. jedoch 0
     • memory_target_max muss auf die Größe des von der Oracle DB verwendeten Tempfs gesetzt werden (hier die genaue Größenangabe), in Byte
     • Das ist eine Sache der Einrichtung, die hoffentlich irgendwo notiert wurde, als die Quelldatenbank eingerichtet wurde
     • Sonst sollte das z.B. in der fstab zu finden sein
     • In docker-compose wird das durch den Service Parameter shm_size geregelt, in Docker ohne compose analog mit --shm-size

   • Für diese Anpassungen einfach das Pfile mit einem Texteditor öffnen, und die fraglichen Zeilen bearbeiten, z.B. (wobei 0 als Zielwert ein Workaround ist):

     Anpassung Pfile

     # VORHER *.memory_max_target=60129542144 *.memory_target=51539607552   # NACHHER *.memory_max_target=0 *.memory_target=0

     
     

     Beispiel für Server mit 16 GB

     *.memory_max_target=12884901888 *.memory_target=8589934592

2. Die FRA muss in jedem Falle temporär auskommentiert werden (Quelle)

   • Das muss später wieder rückgängig gemacht werden, weil die FRA ja durchaus nutzbar sein soll
   • Die Anpassung ist nötig, weil die Oracle DB sonst einen Crosscheck zwischen dem Backup und der aktuellen DB durchführt, wenn ein restore Befehl ausgeführt wird
     
     • Dieser Crosscheck würde fehlschalgen, weil die aktuelle DB eine andere als die im Backup enthaltene ist

   • Das Auskommentieren der FRA verhindert diesen Crosscheck:

     FRA temporär auskommentieren

     # VORHER *.db_recovery_file_dest='/opt/oracle/oradata/fast_recovery_area' *.db_recovery_file_dest_size=107374182400   # NACHHER #*.db_recovery_file_dest='/opt/oracle/oradata/fast_recovery_area' #*.db_recovery_file_dest_size=107374182400

4.2. Restore Controlfile, set DBID

Im Controlfile sind Informationen wie z.B. die Speicherorte der Datafiles und Backups enthalten. Dieses Controlfile haben wir in der Backup-Anleitung ins Autobackup eingeschlossen.

Jetzt benötigen wir den Pfad zu Backup Pfile. Wurde die Backup Anleitung befolgt und die FRA wie hier in Abschnitt 2.4. beschrieben vollständig kopiert, liegt dieses jetzt unter /opt/oracle/oradata/fast_recovery_area/pfile_recovery.ora - wurde das Backup anders erstellt oder/und an einen anderen Ort kopiert, müsste dieser Pfad im Befehl unten angepasst werden.

Um das Contrlfile Backp nutzen zu können, benötigen wir zuerst Pfad und Name von ebendiesem Autobackup (im Container). Hier im Beispiel ist das /opt/oracle/oradata/fast_recovery_area/EXXDB1/autobackup/2021_01_21/o1_mf_s_1062419897_j0lxfsmw_.bkp - das hängt aber von so vielen Parametern ab, dass es mit großer Sicherheit anderswo anders ist, also den Pfad im Befehl unten Anpassen. Zur Struktur der FRA siehe Abschnit 1.4.

Zur Erklärung: Mit Pfile Startup werden dem DBMS die Parameter der Quelldatenbank bekannt. Mit dem Controlfile restore werden Informationen wie die Pfade der Datafiles, Backups und weiterer wichtiger Daten bekannt. Dadurch sollte die in anderen Anleitungen beschriebene Katalogisierung der Dateien unnötig werden. Das Setzen der DBID ist für nachfolgende Schritte wichtig.

4.2.1. DBID nicht bekannt

Es ist für den nächsten Schritt notwendig, die DBID der Quelldatenbank zu kennen. Ist diese bakannt, so kann dieser Abschnitt übersprungen werden, der nächste Schritt ist dann 4.2.2.

Ist die DBID nicht bekannt, so kann sie herausgefunden werden. Denn der Witz ist, dass im Controlfile die Datenbank und ihre Parameter gespeichert sind.

Folgender Weg ist möglich, wobei der Pfad (inkl. Dateiname) zum Autobackup (zweite Zeile) unbedingt angepasst werden muss:

Hier unten finden wir die DBIDs aller bekannten Datenbanken, und da dass Controlfile geladen wurde, ist die der Quelldatenbank auf jeden Fall mit dabei.

Ab 4.2.2. jetzt wieder Schritte, die in beiden Fällen ausgeführt werden müssen (egal, ob die DBID zuvor bekannt war oder nicht). Einige Befehle mögen dem aufmerksamen Leser redundant erscheinen - diese Befehle trotzdem "doppelt" ausführen (sprich: alles genau so machen wie es da steht), sonst kann es zu Fehlern kommen.

4.2.2. DBID bekannt

Diesen Schritt befolgen, sobald die DBID der Quelldatenbank bekannt ist (entweder schon vorher, oder durch 4.2.1. herausgefunden wurde).

Das setzen der DBID ist temporär. Spätestens mit Beenden von RMAN setzt sich dies zurück.

Wird RMAN nachfolgend beendet oder tritt ein signifikanter Fehler auf, muss wieder ab hier begonnen werden.

Folgende Befehle sind jetzt nötig, wobei die DBID und der Pfad (inkl. Dateiname) des Autobackups (zweite Zeile) unbedingt angepasst werden müssen:

Nach dem letzten Schritt ist die DB im Mount State mit den Parametern und Datafile sowie Backup Pfaden der Quelldatenbank.

Die Reihenfolge der Befehle ist sehr wichtig. Deswegen hilft es auch nichts, die Befehle in 4.2.1. schon einmal ausgeführt zu haben...

4.3. SCN

Theoretisch ist dieser Schritt optional, praktische ist jedoch zu raten, diesen Schritt trotzdem durchzuführen. Schon allein, weil an dieser Stelle ggf. Fehler auftauchen.

Hier stehen eine Menge Informationen, u.a. die Pfade der Datafiles und in welchen Backups was verfügbar ist. Für später wird eine SCN eines Backups benötigt. In der Regel ist es sinnvoll die letzte (= neueste) verfügbare "Low SCN" zu nehmen, das ist hier im Beispiel 1372165404 (8. Ziele von unten) - diese erst einmal notieren.

4.4. Restore und Recover

Es gibt zwei Möglichkeiten. Die zweite ist die, welche ich zuerst gefunden habe - diese wird im WWW häufiger als der "richtige" Weg dargestellt. Erstere ist jedoch einfacher, und läuft effektiv fast auf das gleiche hinaus (nur genau umgekehrt).

Hintergrund der Vorgehensweisen ist, dass RMAN keine bereits bestehenden Dateien überschreibt; nähere Erklärung in B.

Gilt für beide Wege:

Im Zweifelsfall empfehle ich Variante A (da sie einfacher ist).

4.4.1. VARIANTE A: Etwas brutal, aber einfach und effektiv

Einfach alle Datafiles wegschieben (im Container).

Anschließend gelingt ein Restore (das dauert einige Zeit), und ein Recover kann folgen (hier die SCN mit der aus Abschnitt 4.3. ersetzen):

Beispielsweise so hier:

4.4.2. VARIANTE B: Etwas vorsichtiger

Diese Variante ist die, welche ich als erste verstanden habe, und welche auch häufiger zu finden ist.

Die Datafiles wurden bereits aus dem Controlfile geladen (genauer: deren Metadaten wie Speicherort, nicht deren Inhalt), deswegen können wir uns diese Anzeigen lassen:

Wir sehen die Dateinummer (1 bis 9), welche für Troubleshooting oder andere Vorgehensweisen (viele Anleitungen im Internet bennen die Files einzeln um) nötig wären. In der letzten Spalte sehen wir den Namen, also den Speicherort. Ist die Dateigröße (zweite Spalte) 0, so gibt es die Datei nicht. Gibt es mindestens ein Datafile, welches schon existiert (eine Größe >0 hat) - und davon ist auszugehen - so müssen wir diese auf irgendeine Art und Weise umbenennen und damit an einen neuen Speicherort verschieben.

Hier legen wir erst einmal nur den neuen Pfad an - der Ordnername ist nicht so wichtig, muss aber der selbe wie später verwendet sein:

Nun müssen dem DBMS die neuen Dateipfade mitgeteilt werden, was in einem RUN-Block mit Restore und Recover durchgeführt wird:

(Erklärung unter dem Codeblock am besten vorher durchlesen)

Vor dem Ausführen des RUN-Block sollten die redolog's gelöscht werden.

(RUN-Block am besten vorher im Texteditor zusammenbasteln, da im RMAN Pfeiltasten nicht funktionieren)

• Die Set-Komandos gelten nur temporär!
• In Zeile zwei brauchen wir den Ordnernamen des im vorherigen Schritt erstellten Ordners
  • Das %b ersetzt das DBMS durch den Dateinamen, anderes ist theoretisch auch möglich, siehe Dokumentation
• Statt Zeile 2 können auch alle Datafiles einzeln umbenannt werden, viele Anleitungen im Internet machen das, es hat den gleichen Effekt (mit mehr Aufwand)
• Zeile 3 legt fest, welcher Stand für die Recovery gesetzt werden soll, ihr die in Abschnitt 4.3. notierte SCN verwenden
• Zeile 4 führt das Restore durch, also das die Datafiles aus dem Backup ausgepackt werden
  • Das dauert einige Zeit (z.B. 30min für 10GB Backup)
  • Hier werden die Datafiles aus dem Backup ausgepackt und im richtigen Pfad angelegt
  • Dieser Schritt ist fast idempotent, erneutes Ausführen dauert (bei gleichen Parametern wie DBID, SCN, usw.) nur noch Sekunden
• Zeile 5 führt das Switch auf die neuen (in Zeile 2 festgelegten und Zeile 4 erstellten) Datafiles durch
• Zeile 6 bringt die DB auf den korrekten konsistenten Stand (recover), das dauert noch mal ein bisschen

4.5. Beenden der Wiederherstellung

Einige Anleitungen lassen diese Schritte weg, vielleicht geht es tatsächlich auch ohne, abgesehen vom Resetlogs.

Die Archivelogs müssen zurückgesetzt werden, was beim Öffnen der Datenbank erfolgt:

Die DB wurde in 4.2. nur "temporär" mit dem veränderten Pfile gestartet. Um das quasi permanent zu machen, muss nun ein Spfile aus dem Pfile erstellt werden.

Dafür nun zuerst alle Änderungen aus 4.1.2. im Pfile wieder rückgängig machen (außerhalb des Containers im FRA-Pfad, wie in 4.1. auch), also z.B. die Nutzung der FRA wieder zulassen:

Und anschließend aus dem veränderten Pfile im RMAN in Container ein permanentes Spfile erstellen (das DBMS sucht den richtigen Pfad aus):

Spfile aus Backup

Alternativ kann das Spfile auch aus dem Autobackup geholt werden (falls alle Parameter identisch sein sollten).

In den meisten Fällen sind aber nicht alle Parameter identisch, weshalb das dann nicht funktioniert.

5. Troubleshooting

5.1. RMAN-06403: could not obtain a fully authorized session

Höchstwahrscheinlich wurde die DB bereits heruntergefahren.

5.2. ORA-01092: ORACLE instance terminated. Disconnection forced

Zum Beispiel so hier:

Problemquelle kann verschieden sein, evtl. hat sich die DB beendet.

Problemlösung: Startup wie im Abschnitt "Restore Controlfile" beschrieben neu durchführen.

5.3. RMAN-06139: WARNING: control file is not current

Während der Aktionen muss das so. Kein Bug, ein Feature.

Danach sollte es durch das Erstellen des Spfiles (Abschnitt "Beenden der Wiederherstellung") behoben werden, weil dann im Spfile alles richtig gesetzt wird.

5.4. ORA-00210: cannot open the specified control file

Der Fehler bedeutet genau das, was dasteht: das Controlfile konnte nicht geöffnet werden. Das kann passieren, wenn Variante A für Restore verwendet wird.

Lösung: Überprüfen, dass das Controfile in das richtige Verzeichnis zurück kopiert wurde. Dateiberechtigung und Besitzer prüfen. Evtl. ab restore Controlfile wiederholen.

5.5. ORA-01078: failure in processing system parameters

• Dieser Fehler ist nicht notwendigerweise etwas schlechtes, denn er verhindert keine Aktionen, aber er sollte eigentlich nicht auftreten
• Ursache ist, dass gleich aus welchem Grund das Pfile nicht gelesen werden konnte
• Wurde die DB mit dem korrekten abgeänderten Pfile in den nomount state gebracht?
• Gehört das Pfile dem oracle user und hat dieser auch Schreibrechte?

5.6. RMAN-04014: startup failed: ORA-00845: MEMORY_TARGET not supported on this system

Dieser Fehler tritt beim Start mit dem Pfile auf, wenn die shm Größe im Pfile (Memory Target) nicht korrekt angepasst wurde. Abändern und DB mit dem abgeänderten Pfile in den nomount state bringen.

5.7. RMAN-04014: startup failed: ORA-27100: shared memory realm already exists

In diesem Falle wurde die shm Größe im Pfile (Memory Target) falsch angepasst. Abändern und DB mit dem abgeänderten Pfile in den nomount state bringen.

5.8. RMAN-06189: current DBID ... does not match target mounted database (...)

Für restore und ähnliche Befehle muss in RMAN (für jede Session einzeln) die DBID auf die der Quelldatenbank gesetzt werden. Sobald das Controlfile restored ist, kann man diese einfach herausfinden:

5.9. RMAN-06172: no AUTOBACKUP found or specified handle is not a valid copy or piece

Mit dieser Fehlermeldung wurde viel gekämpft. Sie scheint sehr unterschiedliche Gründe haben zu können:

• Sind die Dateiberechtigungen korrekt? Der oracle Nutzer muss der Besitzer der Dateien sein und Schreibberechtigungen haben (warum auch immer...)!

• Wurde der richtige Dateiname angegeben (z.B. beim Controlfile restore)?
• Wurde das Pfile angepasst (FRA auskommentiert)?

• Wurde die Datenbank mit dem korrekten Pfile im Nomount-State gestartet?

5.10. RMAN-04014: startup failed: ORA-09925: Unable to create audit trail file

• Existieren die ggf. im Pfile angegebenen Pfade, und hat der oracle Nutzer dort die nötigen Schreibrechte?
• Haben Quell- und Zieldatanbank die gleiche SID?
  • Rein theoretisch wäre das vielleicht nicht unbedingt notwendig, aber dann ist zusätzliche schwarze Magie nötig, welche in dieser Anleitung nicht behandelt wird
• Existieren die Datafile Verzeichnisse?
  • Die Pfade werden aus dem Controlfile geladen
  • Pfade anzeigen mit report schema, Spalte "name", wobei es nicht um die Dateien geht, sondern die Ordner in denen diese liegen
  • Siehe auch nächster Abschnitt
  • Existieren alle diese Ordner?
  • Ist der oracle Nutzer Besitzer aller dieser Ordner?
  • Hat der oracle Nutzer rwx Rechte auf alle diese Ordner?

5.11. No Backup or copy of datafile 1 found to restore

Der Fehler tritt beim restore auf und sieht zum Beispiel so aus:

Die Nummern der Datafiles können andere sein. Sie könnten willkürlich erscheinen, sind sie aber nicht:

Die Fehler treten für die Datafiles auf, welche bereits vorhanden sind (Größe >0), zum Beispiel von der zuvor initialisierten DB. RMAN überschreibt keine bereits vorhandenen Datafiles, deswegen müssen entweder die Datafiles umbenannt, oder die bereits vorhandenen gelöscht werden, siehe den Abschnitt zu den Restore und Recover Varianten.

5.12. RMAN-06571: datafile 1 does not have recoverable copy

Selber Fehler, Datafiles wurden nicht korret behandelt, siehe Abschnitt zu den Restore und Recover Varianten

5.13. RMAN-06094: datafile 1 must be restored

Dieser Fehler tritt auf, wenn ein Recover durchgeführt wird, ohne das ein Restore (erfolgreich) durchgeführt wurde. Also die Schritte für Restore wiederholen.

Insofern meine Notizen korrekt sind trat dieser Fehler auch auf, wenn die Datafiles nicht richtig behandelt wurden (umbenennen bzw. Verschieben Schritt in Restore und Recover Abschnitt).

5.14. XYZ is from different database

Allgemein informativer Befehl zum Auflisten aller dem DBMS bekannten DBs:

5.14.1. Datafile is from different database

• Wurde die FRA im Pfile wirklich auskommentiert und die DB mit dem modifizierten Pfile gestartet?
• Wurde evtl. das Recover mit dem Restore vertauscht?

5.14.2. Controlfile ... from different database

In diesem Falle scheint die DB nicht mit dem korrekten modifizierten Pfile in den nomount state gebracht worden.

5.14.3. ORA-19698: /opt/oracle/oradata/exxdb1/redo01.log is from different database

Dieser Fehler ist bei Tests mehrfach aufgetreten, insbesondere in Abschnitt 4.4.2. Die genauen Gründe sind mir Schleierhaft.

Lösung war zumeist, fragliche Redologs zu löschen, und ab Restore/Recover zu wiederholen.

5.15. Probleme bei der initialen Einrichtung

5.15.1. RMAN show all; ist nicht möglich

der nachfolgende Fehler kann auftreten wenn ORACLE_SID und ORACLE_HOME nicht identisch sind (Groß/Kleinschreibung ist relevant)

Das Problem ist mir aufgefallen, nachdem ich auch mit sqlplus keine Statement absetzen konnte:

Ursache/Lösung:

The ORA-01034 is a result of a discrepancy between ORACLE_HOME and ORACLE_SID

To resolve ORA-01034, be sure that the ORACLE_HOME and ORACLE_SID properly match within the files /etc/oratab or /var/opt/oracle/oratab