Oracle 12c - Das umfassende Handbuch

Kapitel 18

Recovery-Szenarien für Experten

424

4. Verwenden Sie den Recovery Advisor, wenn Sie an der einen oder anderen Stelle

unsicher sind oder eine zweite Meinung einholen wollen.

5. Planen Sie, falls erforderlich, die Wiederherstellungen gemeinsam mit anderen

betroffenen IT-Bereichen wie Betriebssystemadministration, Netzwerk oder

Storage.

6. Führen Sie den Wiederherstellungsprozess durch.

7. Erstellen Sie sofort eine Komplettsicherung, nachdem die Datenbank wieder-

hergestellt ist.

Es ist immer wichtig, bei Störfällen im Betriebsumfeld die Ruhe zu bewahren

sowie durchdacht und besonnen zu reagieren. Lassen Sie sich nicht von Hektik-

machern beeinflussen, die dann vielleicht noch inkompetente Vorschläge unter-

breiten. Wenn Sie verantwortlicher Manager im Support-Umfeld sind, dann

schützen Sie ihre Datenbankadministratoren vor solchen Einflüssen und lassen

Sie sie am Problem arbeiten. Auch wenn dies banal erscheint, habe ich in der Pra-

xis häufig das Gegenteil erfahren.

18.1 Recovery und Strukturänderungen

Strukturänderungen der Datenbank zwischen Sicherung und Wiederherstellungs-

zeitpunkt erschweren die Recovery-Strategie. Zwar erleichtert Oracle mit jeder

neuen Version die Behandlung von solchen Sonderfällen, es gibt jedoch auch in

Oracle 12c immer noch einige Punkte zu beachten.

18.1.1 Szenario 1

Im vorliegenden Szenario wurde eine Komplettsicherung erstellt. Die Sicherung

besteht aus der Datenbank, den Archived Redo Log-Dateien und der Kontrolldatei,

die mit der Autobackup-Funktion gesichert wurde.

Nach der Sicherung wurde eine neue Tablespace TOOLS erstellt und dem Table-

space USERS das Datafile users02.dbf hinzugefügt. Der Tablespace TOOLS ist in

Benutzung und enthält die Tabelle tools_table. Der Datenbankadministrator legt

Tipp

In den folgenden Recovery-Szenarien werden Dateien der Datenbank physika-

lisch gelöscht. Es besteht die Gefahr, dass die Originaldatenbank in komplizier-

ten Fällen nicht wieder hergestellt werden kann. Führen Sie deshalb zusätzlich

eine Offline-Sicherung durch, indem Sie alle Dateien in ein separates Verzeich-

nis kopieren. Gleichzeitig können Sie mit dieser Methode vor jedem neuen Sze-

nario den Originalzustand der Datenbank wieder herstellen.

18.1

Recovery und Strukturänderungen

425

eine zusätzliche Online Redo Log-Gruppe im System an. Danach erfolgt ein

Backup der Archived Redo Log-Dateien mit Autobackup der Kontrolldatei.

Es kommt zu einem Incident, der ein Disaster Recovery erfordert. Zur Simulation

des Vorfalls werden alle Datafiles, Kontrolldateien, Online- und Archived Redo

Log-Dateien gelöscht.

Führen Sie die folgenden Schritte durch, um den Zustand nach dem Incident her-

zustellen:

1. Erstellen Sie mit dem Recovery Manager eine Sicherung von Datenbank und

Archived Redo Log-Dateien.

2. Erstellen Sie den Tablespace TOOLS und legen Sie darin eine Tabelle an.

3. Hängen Sie an den Tablespace USERS ein weiteres Datafile an.

$ rman target / catalog rman/rman@rman

Recovery Manager: Release 12.1.0.1.0 - Production on Tue Mar 25 14:14:19

2014

Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights

reserved.

connected to target database: MITP2 (DBID=628234225)

connected to recovery catalog database

RMAN> run {

2> BACKUP INCREMENTAL LEVEL 0 DATABASE;

3> BACKUP ARCHIVELOG ALL DELETE INPUT;

4> }

Starting backup at 25-MAR-14

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=257 device type=DISK

. . .

Starting Control File and SPFILE Autobackup at 25-MAR-14

piece handle=/opt/oracle/fast_recovery_area/MITP2/autobackup/2014_03_25/

o1_mf_s_843142547_9m30d3st_.bkp comment=NONE

Finished Control File and SPFILE Autobackup at 25-MAR-14

SQL> CREATE TABLESPACE tools

2 DATAFILE '/opt/oracle/oradata/MITP2/tools01.dbf' SIZE 10m;

Tablespace wurde angelegt.

SQL> CREATE TABLE tools_table(

2 datum DATE)

3 TABLESPACE tools;

Tabelle wurde erstellt.

SQL> INSERT INTO tools_table VALUES (sysdate);

1 Zeile wurde erstellt.

SQL> COMMIT;

Transaktion mit COMMIT abgeschlossen.

Kapitel 18

Recovery-Szenarien für Experten

426

4. Fügen Sie eine weitere Online Redo Log-Gruppe hinzu.

5. Erstellen Sie eine Sicherung der Archived Redo Log-Dateien. Achten Sie darauf,

dass das Controlfile Autobackup aktiviert ist.

6. Simulieren Sie jetzt den Crash der Datenbank, indem Sie alle Kontrolldateien,

Datafiles, Tempfiles, Online und Archived Redo Log-Dateien löschen.

18.1.2 Lösung 1

Es muss ein Disaster Recovery durchgeführt werden. Es ist ein komplettes Rück-

speichern der Datenbank und ein Recovery bis zur zuletzt gesicherten Archived

Redo Log-Datei erforderlich. Doch was geschieht mit dem neu angelegten Table-

space und dem neuen Datafile? Offensichtlich sind diese ja nicht im letzten Full-

Backup enthalten.

Beginnen Sie mit dem Rückspeichern der Kontrolldateien und öffnen Sie die

Datenbank im MOUNT-Status.

In den nächsten Schritten folgen das Rückspeichern der Datafiles und das Reco-

very. Da die Online Redo Log-Dateien mit dem Crash verloren gegangen sind,

muss ein Incomplete Recovery durchgeführt werden. Es stellt sich die Frage, wie

weit der Recovery-Prozess laufen soll. Kennt die Datenbank die zuletzt gesicherte

Sequence Number? Die Antwort ist Ja, denn das Autobackup der Kontrolldatei war

aktiviert und die Kontrolldatei wurde nach dem letzten Archivelog-Backup gesi-

chert. Also fragen wir die Datenbank nach der Sequence Number. Beachten Sie

dabei, dass es – so wie in diesem Beispiel – möglicherweise mehrere Inkarnatio-

nen der Datenbank gibt.

SQL> ALTER TABLESPACE users

2 ADD DATAFILE '/opt/oracle/oradata/MITP2/users02.dbf'

3 SIZE 10m;

Tablespace wurde geändert.

SQL> ALTER DATABASE

2 ADD LOGFILE GROUP 4

3 ('/opt/oracle/oradata/MITP2/redo04.log') SIZE 52428800;

Datenbank wurde geändert.

RMAN> BACKUP ARCHIVELOG ALL DELETE INPUT;

RMAN> STARTUP NOMOUNT

RMAN> RESTORE CONTROLFILE;

RMAN> ALTER DATABASE MOUNT;