Oracle 12c - Das umfassende Handbuch

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