next High-Performance-Tuning
up Fundamentals
previous Backup / Recovery
  Contents   Index

Subsections


Recovery Manager (RMAN)

Oracle liefert den Recovery Manager alsein leistungsstarkes und mächtiges Utility zur Sicherung und Wiederherstellung von Datenbanken. Hierbei speichert der Recovery Manager die durchgeführten Sicherungs- und Wiederherstellungsoperationen. Diese werden entweder in der Control-Datei oder in einem sogenannten Recovery-Catalog gespeichert.

Die Sicherung erfolgt in einem nur vom Recovery Manager lesbaren Format und erfolgt in einer Datei oder auf Band. Für die Sicherung auf Band muss ein Medien-Manager installiert sein (z.B. der Legato Storage Manager). Nur ein Benutzer mit SYSDBA-Priviliegien kann Sicherungs- und Wiederherstellungsoperationen durchführen.


Inkrementelle Sicherung

Ein inkrementelle Sicherung basiert auf einer Ebenen-Struktur. Es werden nur die Blöcke gesichert, die sich seit der letzten Sicherung der gleichen Ebene oder einer tieferen Ebene verändert haben. Schauen wir uns das Ganze an einem Beispiel etwas genauer an:

Sie haben eine Level 0-Sicherung durchgeführt.
Sie führen monatlich eine Level 1-Sicherung durch.
Sie führen wöchentlich eine Level 2-Sicherung durch.
Sie führen täglich eine Level 3-Sicherung durch.

Angenommen, es tritt ein Datenbankfehler genau nach 3 Monaten, 2 Wochen und 3 Tagen auf. In diesem Fall muß die Level 0-Sicherung zurückgesichert werden. Im Anschluß müssen die 3 monatlich durchgeführten Level 1-Sicherungen wiederhergestellt werden. Nun müssen noch die 2 wöchentlich durchgeführten Level 2-Sicherungen durchgeführt werden. Zuletzt müssen nun die 3 täglich durchgeführten Level 3-Sicherung wiederherstellen.


CONFIGURE / REPORT / LIST / SHOW

Default
RMAN> configure default device type disk format '/db01/BACKUP/\$U';
disk - Festplatte
sbt - Tape
Per Default wird in $ORACLE_HOME/database gespeichert.

Dauerhafte Konfigurationseinstellungen anzeigen

RMAN> show all;
Auflisten der Backups aller Dateien in der Datenbank
RMAN> list backup of database;
Alle Backup Sets mit der Datendatei users01.dbf anzeigen
RMAN> list backup of datafile "/db01/ORADATA/u03/users01.dbf";
Alle Kopien der Datendateien im Tablespace SYSTEM auflisten.
RMAN> list backup of tablespace "SYSTEM";
REPORT - Erstellt eine detaillierte Analyse des Repository

Anzeige der Datenbankstruktur

RMAN> report schema
Für welche Dateien ist ein Backup erforderlich?
RMAN> report need backup;
Welche Backup sind veraltet und können gelöscht werden?
RMAN> report obsolete;


Sicherung mit Control-Datei

Neben der Möglichkeit, RMAN-Daten in einem Recovery-Catalog zu speichern, können Sie auch RMAN-Daten in den Control-Dateien speichern. Hierbei ist es von enormer Bedeutung, dass Sie Ihre Control-Dateien über mehrere Platten verteilt haben. Es muss immer eine aktuelle Control-Datei vorhanden sein. Falls alle Control-Dateien verloren gegangen sein sollten, und Sie trotzdem die Datenbank wiederherstellen müssen, so können Sie auch von einer Sicherung der Control-Datei die Wiederherstellung per RMAN initiieren.

In unserem Beispiel gehen wir davon aus, dass die Datenbank testdb29 mit dem RMAN gesichert werden muss. Als erstes starten wir hierfür den RMAN.

rman target sys/sys@testdb29 nocatalog
RMAN>
Nun wird die eigentliche Sicherung der Datenbank durchgeführt. Hierfür wird als erstes ein Kanal zugewiesen.
ALLOCATE CHANNEL channelname 
         TYPE medientyp_des_sicherungsmediums 
         FORMAT Bennenungskonvention_der_Sicherungsdatei;
Wir wollen in unserem Beispiel in eine Datei des Ordners /backup01 sichern. Der Name der Sicherungsdatei sollte folgende Variablen enthalten:

%u - 8-Zeichen-String (Nummer des Sicherungsatzes, Erstellungsdatum).
%s - Nummer des Sicherungssatzes.
%p - Teilnummer des Sicherungssatzes (beginnt bei 1).

Wir benutzen demnach folgende Anweisung für die Zuweisung eines Kanals für die Sicherung:

ALLOCATE CHANNEL s1 
         TYPE disk 
         FORMAT '/backup01/b_%u_%s_%p';
Anschließend erfolgt die eigentliche Sicherung.
BACKUP DATABASE;
Diese beiden Anweisungen werden nun noch durch ein RUN zusammengefasst.
run {
  ALLOCATE CHANNEL s1 
           TYPE disk 
           FORMAT '/backup01/b_%u_%s_%p';
  BACKUP DATABASE;
}


Recovery

Für das Wiederherstellen mit dem RMAN ist es wichtig, über eine Control-Datei zu verfügen. Als erstes erstellen wir eine kleine Beispieltabelle, um nach dem Wiederherstellen sehen zu können, ob tatsächlich alles bis zum Crash wiederhergestellt werden konnte.
create table obst(nr number(3), obstname varchar2(10)) 
  tablespace users;
insert into obst values(1,'Erdbeeren');
insert into obst values(2,'Kirschen');
insert into obst values(3,'Himbeeren');
commit;
Nun fahren wir die Instanz herunter und löschen die Datendatei users01.dbf, um einen Crash zu simulieren.
shutdown immediate;
host;
rm /oracle/oradata/testdb29/users01.dbf
Anschließend versuchen wir, die Instanz wieder hochzufahren.
startup;
...
Datenbank mit Mount angeschlossen.
ORA-01157: Datendatei 3 kann nicht identifiziert/gesperrt werden
           Siehe DBWR-Trace-Datei.
ORA-01110: Datendatei 3: '/oracle/oradata/testdb29/users01.dbf'
Wir müssen nun die Datendatei mit RMAN wiederherstellen.
  1. Im ersten Teil muss wiederum ein Kanal zugeordnet werden:
    ALLOCATE CHANNEL s1 TYPE disk FORMAT '/backup01/b_%u_%s_%p';
    
  2. Im zweiten Teil muss die Datendatei wiederhergestellt werden:
    RESTORE DATAFILE /oracle/oradata/testdb29/users01.dbf;
    
  3. Im dritten Teil müssen alle Transaktionen, die seit der Sicherung durch RMAN durchgeführt wurden, auf diese Datendatei angewendet werden.
    RECOVER DATAFILE /oracle/oradata/test/users01.dbf;
    
Diese Teile müssen nunmehr mit RUN zusammengefasst und mit dem RMAN ausgeführt werden.
RUN {
  ALLOCATE CHANNEL s1 TYPE disk FORMAT '/backup01/b_%u_%s_%p';
  RESTORE DATAFILE '/oracle/oradata/test/users01.dbf';
  RECOVER DATAFILE '/oracle/oradata/test/users01.dbf';
}
Nun versuchen wir, die Datenbank zu öffnen und schauen, ob unser Obst wieder da ist.
alter database open;
select * from obst;
 NR  OBSTNAME
--------------
  1  Erdbeeren
  2  Kirschen
  3  Himbeeren


Automatische Sicherung der Control-Datei

Sie können die Control-Datei mit Hilfe von RMAN automatisch sichern lassen.
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON
In folgenden Fällen wird dann die Control-Datei gesichert.
  1. Nach jeder Copy oder Backup-Anweisung an der RMAN-Eingabeaufforderung.
  2. Immer wenn innerhalb eines RUN-Blockes einem Copy- oder Backup-Befehl eine anderen Anweisung folgt.
  3. Am Ende eines Run-Blockes, wenn die letzte Anweisung ein Copy oder Backup-Anweisung ist.
  4. Bei strukturellen Änderungen an der Datenbank.


Sicherung mit Recovery-Catalog

Der Recovery-Catalog speichert alle Sicherungs- und Wiederherstellungsoperationen und erlaubt neben der Wiederherstellung eine Reihe von nützlichen Analysefunktionen. Der Recovery-Catalog benötigt einen eigenen Tablespace. Diesen Tablespace in der zu sichernden Datenbank zu erstellen wäre ein Fehler. Im Falle des Crashs der Datenbank wäre auch der Recovery-Catalog nicht mehr ansprechbar, und damit wäre eine Wiederherstellung nicht mehr möglich. Empfehlenswert ist das Erstellen einer eigenen Datenbank für den Recovery-Catalog und das Sichern dieser Recovery-Catalog-Datenbank mit Hilfe eines Cold- oder Hot-Backups.


Recovery-Catalog erstellen

Voraussetzung für das Erstellen eines Recovery-Cataloges ist ein eigener Tablespace. Desweiteren brauchen wir einen Benutzer, der Besitzer dieses Recovery-Cataloges ist. Hierfür muss sich diesem Benutzer die Rolle RECOVERY_CATALOG_OWNER, CONNECT und RESOURCE zugewiesen werden.
  1. Erstellen der Catalog-Datenbank (in unserem Beispiel heißt diese Datenbank cat). Sie können hierfür den Database Configuration Assistent benutzen.
  2. Neuen Tablespace erstellen
    create tablespace rman_ts 
       datafile '/rman-katalog/rman_ts01.dbf' size 20M 
       default storage (initial 100K next 100K pctincrease 0)
    ;
    
  3. Erstellen des RMAN-Users (in unserem Beispiel heißt dieser Benutzer rman).
    create user rman identified by rman 
      default tablespace users 
      temporary tablespace temp
    ;
    grant connect to rman;
    grant ressource to rman;
    grant recovery_catalog_owner to rman;
    
  4. Der entsprechende Catalog wird nun erstellt. Dies muss mit Hilfe des Recovery Manager RMAN geschehen. Hierfür müssen Sie den Recovery Manager starten und sich mit der entsprechenden Catalog-Datenbank verbinden.
    rman catalog rman/rman@cat
    RMAN> create catalog tablespace 'users';
    
  5. Die zu sichernde Datenbank oder Datenbanken müssen nun registriert werden. Hierfür starten Sie wieder der Recovery Manager RMAN unter Angabe der Catalog-Datenbank und unter Angabe der Zieldatenbank.
    rman catalog rman/rman@cat target internal/oracle@testdb29
    RMAN> register database;
    
Die Sicherung selbst erfolgt wie die Sicherung einer Control-Datei.

Die Sicherung mit einem Recovery-Catalog bietet darüber hinaus eine Reihe von nützlichen Erweiterung. So können Sie im Recovery-Catalog Skripte speichern, welche die Sicherung einer Datenbank oder Teile der Datenbank (Tablespaces, Dateien etc.) automatisieren. Folgendes Skript führt ein Cold Backup der Datenbank testdb29 durch:

replace script 'Vollsicherung' {
  shutdown immediate;
  startup mount;
  allocate channel ch1 type disk format '/backup/%d_DB_%u_%s_%p';
  backup database include current controlfile;
  release channel ch1;
  alter database open;
}
Aufgerufen wird das Skript folgendermaßen:
run {execute script Vollsicherung;}
Das Listing des Skriptes können Sie sich so anschauen:
print script "Vollsicherung";


Berichts- und Überprüfungsfunktionen

Anzeigen aller Sicherungsdetails.
list backup;
Anzeigen bzw. Löschen von Sicherungen, die nicht mehr für das Wiederherstellen benötigt werden.
report obsolete;
delete obsolete;
Anzeigen bzw. Löschen von Sicherungen, die nicht mehr für das Point In Time-Wiederherstellen innerhalb der letzten sieben Tage benötigt werden.
report obsolete recovery window of 7 days;
delete obsolete recovery window of 7 days;
Anzeigen bzw. Löschen von Sicherungen, bei denen zwei neuere Kopien zur Verfügung stehen.
report obsolete redundancy = 2 device type disk;
delete obsolete redundancy = 2 device type disk;
Anzeigen von Dateien, die nicht wiederhergestellt werden können.
report unrecoverable database;
Synchronisierung des Kataloges mit den Control-Dateien.
resync catalog
Überprüfen, ob die Sicherungsdateien existieren.
crosscheck backup;
Ein Cross-Check markiert die Sicherungen, die gemäß der Retention Policy noch benötigt werden, entweder als AVAILABLE (falls die Sicherungen vefügbar sind) oder als EXPIRED (wenn die Sicherungen nicht verfügbar sind) Mit dem folgenden Befehl können Sie sich die Sicherungen, die nicht verfügbar sind, anzeigen lassen.
LIST EXPIRED;


Umbenennen einer Datei bei der Wiederherstellung

Häufig tritt der Fall ein, dass eine Wiederherstellung aufgrund eines Plattenausfalls notwenig wird. Hierbei ist zu beachten, dass bei einer normalen Wiederherstellung die Dateien immer an ihrem Originalort wiederhergestellt werden. Wird die fehlende Platte jedoch nicht ersetzt, so muß die dort gespeicherte Datei oder Dateien an einem anderen Ort wiederhergestellt werden.
SET NEWNAME FOR DATAFILE x TO location;
Schauen wir uns das an einem kleinen Beispiel etwas genauer an. Wir gehen von einer Datenbank aus, bei der sich die Datendatei users01.dbf auf /data_01/users01.dbf befindet. Diese Platte fällt nunmehr aus und Sie möchten die Datendatei users01.dbf auf der /data_02/ wiederherstellen.
run {
  SET NEWNAME FOR DATAFILE '/data_01/users01.dbf ' TO '/data_02/users01.dbf ';
  RESTORE DATAFILE x; 
  RECOVER DATAFILE x;
}
Durch set newname wird für die datei /data_01/users01.dbf der neue Speicherort /data_02/users01.dbf festgelegt. Anschließend wird diese Datei wiederhergestellt (schon an dem neuen Speicherort) und alle notwendigen Transaktionen angewendet. Danach kann die Datenbank wieder normal geöffnet werden.


Parallelisieren von Kanälen

Kanäle können aus Geschwindigkeitsgründen parallele Operationen durchführen. Schauen wir uns hierfür als erstes folgendes Beispiel an:
run {
  allocate channel c1 type disk;
  allocate channel c2 type disk;
  allocate channel c3 type disk;
  backup datafile 1;
  backup datafile 2;
  backup datafile 3;
}
In diesem Beispiel werden zwar drei Kanäle zugeordent, es erfolgen jedoch drei unabhängige Befehle für die Sicherung
backup datafile 1;
backup datafile 2;
backup datafile 3;
Oracle arbeitet erst eine Anweisung komplett ab, bevor weitere Anweisungen durchgeführt werden. Folglich ist immer nur ein Kanal zu aktiv. Versuchen wir, das ganze etwas umzuschreiben:
run {
  allocate channel c1 type disk;
  allocate channel c2 type disk;
  allocate channel c3 type disk;
  backup datafile 1, 2, 3;
}
In diesem neuen Skript führt eine Sicherungsanweisung die Sicherung für die drei Datendateien durch (BACKUP DATAFILE 1, 2, 3). Folglich sind alle drei Kanäle aktiv und können genutzt werden.

Ähnlich verhält es sich bei der Sicherung einer gesamten Datenbank. Nehmen wir an, dass eine Datenbank aus 16 Dateien besteht. Sie führen nun folgendes kleine Skript zur Sicherung der Datenbank aus:

run {
  allocate channel c1 type disk;
  allocate channel c2 type disk;
  allocate channel c3 type disk;
  backup database;
}
Auch in diesem Beispiel kann nur ein Kanal genutzt werden, da die Datenbank als Ganzes in eine Datei gesichert wird. Schreiben wir nun das Ganze etwas um:
run {
  allocate channel c1 type disk;
  allocate channel c2 type disk;
  allocate channel c3 type disk;
  backup database filesperset 4;
}
Da in ein Sicherungsset nur vier Dateien eingeschlossen werden können (FILESPERSET=4), erfolgt die Sicherung in vier Sicherungssets (16 Dateien - >vier Dateien je Set - >4 Sets). In diesem Fall können alle Kanäle benutzt werden, da in vier Sets gesichert wird.


Automatische Kanalzuweisung

Sie können den Standardgrad bezugnehmend auf die parallele Ausführung angeben.
CONFIGURE DEVICE TYPE DISK PARALLELISM 4;
Der Parallelitätsgrad wird hierdurch auf vier festgelegt. Das bedeutet, dass im Zuge einer Sicherung auch vier Kanäle genutzt werden können. Nehmen wir an, Sie führen folgende Anweisung zur Sicherung Ihrer Datendateien 1,2 und 3 aus:
run {
  backup datafile 1, 2, 3;
}
In diesem Fall werden drei Kanäle zugeordnet und für die Sicherung benutzt.


Trial Recovery

Mit Hilfe eines Trial Recovery ist es möglich, eine Wiederherstellung von Redo-Logs 'zu simulieren'. Trial Recovery kommt zum Einsatz, wenn Logs, die wiederhergestellt werden müssen, korrupte Blöcke beinhalten. Die korrupten Blöcke können in der Alert-Log-Datei eingesehen werden. Nach Beendigung der Wiederherstellung werden alle Änderungen rückgängig gemacht. Die korrupten Blöcke werden im Speicher markiert.

Nachdem der Administrator nun weiß, wie viel und welche Blöcke der Redo-Log-Dateien korrupt sind, kann er entscheiden, ob er die Wiederherstellung an diesem Punkt abbricht und die Datenbank mit OPEN RESETLOGS öffnet oder ob er die Wiederherstellung weiterführt und mit ALLOW n CORRUPTION eine gewisse Anzahl korrupter Blöcke 'zulässt'.


FAST_START_MTTR_TARGET

Durch FAST_START_MTTR_TARGET können Sie festlegen, wie lange das Crash-Recovery maximal dauern soll. Angenommen, Sie setzen FAST_START_MTTR_TARGET auf 180, so bedeutet diese Einstellung, dass die Instanz nach einem Fehler (Stromausfall etc.) nach maximal 180 Sekunden, also 3 Minuten, wieder verfügbar ist.

Durch die Einstellung FAST_START_MTTR_TARGET wird also bestimmt, wann Dirty Blocks vom Cache in die Datendateien geschrieben werden. Es wird das Checkpointverhalten verändert und gemäß den getroffenen Einstellungen angepasst.

Folgende Optionen sind in diesem Fall überflüssig:

LOG_CHECKPOINT_INTERVAL
Gibt an, wie oft ein Checkpoint ausgelöst wird, basierend auf der Anzahl der in die Logs geschriebenen Betriebssystemblöcke

LOG_CHECKPOINT_TIMEOUT
Gibt an, wie oft ein Checkpoint ausgelöst wird, basierend auf Zeit seit dem letzten Checkpoint

FAST_START_IO_TARGET
Gibt die maximale Anzahl von IO-Vorgängen für ein Rollforward an, die im Fehlerfall durchgeführt werden müssten. Ist diese Anzahl überschritten, so werden die notwendigen Schritte (Schreiben von Dirty Blocks auf Platte und Setzen von Checkpoints) durchgeführt, um die Anzahl der IO's für ein Rollforward wieder unter den Wert von FAST_START_IO_TARGET zu bringen.


Block Media Recovery

Wenn nur bestimmte Blöcke einer Datei beschädigt sind, so können Sie ein sogenanntes Block Media Recovery durchführen. Hierbei werden nur die Blöcke, die defekt sind, zurückgespielt. Die Datendatei kann dabei Online sein. Hier ein Beispiel:
blockrecover datafile 12 block 1,2,3,4,5 datafile 32 block 10120,10121


Retention Policy

Mit Hilfe der Retention Policy ist es möglich sicherzustellen, dass Sicherungen bis zu einem bestimmten Zeitpunkt in der Vergangenheit verfügbar sind. Mit dem folgenden Befehl setzen Sie die Retention Policy auf 28 Tage. Alle älteren Sicherungen werden als Obsolete gekennzeichnet.
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 28 DAYS;
Nun können Sie alle älteren Sicherungen löschen. Hierfür müssen Sie zuvor einen Kanal für die Wartung zuweisen und im Anschluss wieder freigeben:
ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK;
DELETE OBSOLETE;
RELEASE CHANNEL;
Hinweis: Die Default-Retention-Policy entspricht der REDUNDANCY von 1. Das bedeutet, dass 1 Sicherungs-Set jeweils aufbewahrt wird. Durch folgenden Befehl wird die Retention Policy wieder auf Ihren ursprünglichen Default-Wert (REDUNDANCY 1) gesetzt.
CONFIGURE RETENTION POLICY CLEAR;

Übung Vollsicherung mit RMAN

Übungen siehe Seite [*].
next High-Performance-Tuning
up Fundamentals
previous Backup / Recovery
  Contents   Index


Stefan Hietel dama.go GmbH, Robert Warnke http://rowa.giso.de