Kapitel 18
Recovery-Szenarien für Experten
432
Überprüfen Sie noch, ob die Tabelle in den neuen Datafiles wieder hergestellt
wurde.
Dieses Szenario hätte allein mit dem Recovery Manager nicht bewältigt werden
können. Das Verhalten von RMAN ist in dieser Situation etwas merkwürdig. Was
wäre passiert, wenn wir versucht hätten, das Recovery bis zur letzten Archived
Redo Log-Datei mit RMAN durchzuführen? Der Recovery Manager hätte die fol-
gende Meldung gebracht:
RMAN führt das Recovery nicht bis zu Ende, bleibt genau wie SQL*Plus am nicht
vorhandenen Datafile hängen und schreibt die Datei UNNAMEDnnnnn. Der
Recovery Manager bringt an dieser Stelle keine Fehlermeldung und erweckt den
Eindruck, dass der Recovery-Prozess erfolgreich durchgelaufen sei.
18.2 Der Trick mit den Redo Log-Dateien
Ein Incomplete Recovery ist in einigen Havariesituationen unumgänglich. Es hat
den Nachteil, dass ein, möglicherweise auch geringer, Datenverlust entsteht.
Gleichzeitig wird eine neue Inkarnation der Datenbank erschaffen. Das folgende
Szenario zeigt, wie in einigen Situationen ein Incomplete Recovery vermieden
und stattdessen ein Complete Recovery durchgeführt werden kann.
Die betroffene Datenbank wird regelmäßig durch Full-Backups und Archivelog-
Backups gesichert. Infolge eines Ausfalls von Diskgruppen auf dem Storage-Sub-
system kommt es zum Crash der Datenbank. Nachdem die Disks wieder verfügbar
gemacht werden, wird der folgende Verlust an Dateien festgestellt:
Verlust aller Datafiles.
Verlust der Online Redo Log-Gruppen 1 und 2.
SQL> ALTER DATABASE
2 ADD LOGFILE GROUP 8
3 ('/opt/oracle/oradata/MITP2/redo04.log') SIZE 104857600;
Datenbank wurde geändert.
SQL> SELECT COUNT(*) FROM tools_table;
COUNT(*)
----------
20000
archived log file name=/opt/oracle/oradata/MITP2/redo02.log thread=1
sequence=25
media recovery complete, elapsed time: 00:00:01
Finished recover at 03-APR-14
18.2
Der Trick mit den Redo Log-Dateien
433
Die Kontrolldateien, die Redo Log-Gruppe 3 sowie alle Archived Redo Log-Dateien
haben den Incident schadlos überstanden.
Der erste Schritt für die Wiederherstellung der Datenbank besteht im Zurückspei-
chern der Datafiles vom letzten RMAN-Backup. Da die Kontrolldateien vollständig
erhalten sind, könnten die aktuellen anstelle der gesicherten für den Recovery-Pro-
zess verwendet werden. Allerdings wäre mit den aktuellen Kontrolldateien ein
Incomplete Recovery nicht möglich. Durch den Verlust von zwei Online Redo Log-
Gruppen scheint ein Incomplete Recovery die einzige Lösung zu sein. Doch
schauen wir uns die Situation etwas genauer an!
Mithilfe der Alert-Datei kann nachvollzogen werden, welche Redo Log-Gruppe vor
dem Crash den Status Current hatte:
Das war genau die Redo Log-Gruppe, die nach dem Crash wieder unbeschadet zur
Verfügung steht, nämlich die Gruppe Nummer 3. Die Dateien der Redo Log-Grup-
pen 1 und 2 sind zwar verloren gegangen, allerdings wurden sie archiviert, und die
Archived Redo Log-Dateien sind vollständig erhalten. Eine Überprüfung zeigt,
dass die zugehörigen Archived Redo Log-Dateien verfügbar sind.
Unter diesen Voraussetzungen kann ein Complete Recovery durchgeführt wer-
den. Zuerst müssen die Datafiles aus dem letzten Backup zurückgespeichert
werden.
Die Idee für den Recovery-Prozess ist, die fehlenden Online Redo Log-Dateien aus
den Archived Redo Log-Dateien zu erzeugen und ein Complete Recovery durchzu-
führen. Die Archived Redo Log-Dateien befinden sich im Archivelog-Verzeichnis:
Problematisch an der Stelle ist, dass die Archived Redo Log-Dateien nicht die
Größe der Online Redo Log-Dateien besitzen. Sie werden durch den Archiver-Pro-
Thread 1 advanced to log sequence 8
Current log# 2 seq# 8 mem# 0: /opt/oracle/oradata/MITP/redo02.log
Thread 1 advanced to log sequence 9
Current log# 3 seq# 9 mem# 0: /opt/oracle/oradata/MITP/redo03.log
RMAN> RUN {
2> STARTUP MOUNT;
3> RESTORE DATABASE;
4> }
. . .
Finished restore at 05.04.2014
-rw-r----- 1 oracle orainst 281600 Apr 5 20:18 1_7_651246119.dbf
-rw-r----- 1 oracle orainst 1024 Apr 5 20:18 1_8_651246119.dbf
Kapitel 18
Recovery-Szenarien für Experten
434
zess in der Größe erzeugt, wie sich Daten in den Online Redo Log-Dateien befin-
den. Leere Blöcke werden nicht archiviert.
Das Problem lässt sich mit dem Unix-Kommando dd lösen. Im ersten Schritt wer-
den leere Online Redo Log-Dateien in der erforderlichen Größe erstellt:
Das dd-Kommando verfügt über die Option notrunc. Dabei wird die aktuelle Größe
der Zieldatei beibehalten, falls sie größer als die Originaldatei ist.
Mit diesem Vorgehen wurden die fehlenden Online Redo Log-Dateien wieder her-
gestellt, und alle Gruppen stehen der Datenbank zur Verfügung. Die Größe aller
Dateien ist identisch.
Unter diesen Voraussetzungen kann ein Complete Recovery der Datenbank
gestartet werden:
$ dd if=/dev/zero of=/opt/oracle/oradata/MITP2/redo01.log bs=512 count=102401
102401+0 records in
102401+0 records out
52429312 bytes (52 MB) copied, 0.613282 seconds, 85.5 MB/s
$ dd if=/dev/zero of=/opt/oracle/oradata/MITP2/redo02.log bs=512 count=102401
102401+0 records in
102401+0 records out
52429312 bytes (52 MB) copied, 0.614383 seconds, 85.3 MB/s
$ dd if=/opt/oracle/archive/MITP2/1_7_651246119.dbf of=/opt/oracle/oradata/
MITP2/redo01.log conv=notrunc
550+0 records in
550+0 records out
281600 bytes (282 kB) copied, 0.014138 seconds, 19.9 MB/s
$ dd if=/opt/oracle/archive/MITP2/1_8_651246119.dbf of=/opt/oracle/oradata/
MITP2/redo02.log conv=notrunc
2+0 records in
2+0 records out
1024 bytes (1.0 kB) copied, 6.824e-05 seconds, 15.0 MB/s
-rw-r--r-- 1 oracle orainst 52429312 Apr 5 20:25 redo01.log
-rw-r--r-- 1 oracle orainst 52429312 Apr 5 20:25 redo02.log
-rw-r--r-- 1 oracle orainst 52429312 Apr 5 20:25 redo03.log
RMAN> RUN {
2> RECOVER DATABASE;
3> ALTER DATABASE OPEN;
4> }
Starting recover at 05.04.2014 20:24:14

Get Oracle 12c - Das umfassende Handbuch now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.