next Recovery Manager (RMAN)
up Fundamentals
previous Shared Server
  Contents   Index

Subsections


Backup / Recovery


DB Files überprüfen

Eine Datendatei kann mit dem Shell-Tool dbverify überprüft werden. Dieses Shell-Tool ist günstig für Scripte zur Überprüfung des Backups.
dbv file=SYSTEM01.DBF
Anzeige defekter Datenfiles.
select * from v$recover_file;
Anzeige benötigter Redo-Logs.
select * from v$recovery_log;
Anzeige Archive Logs.
select * from v$archived_log;


OFFLINE-Backup - NOARCHIVELOG

Beim OFFLINE-Backup werden alle notwendigen Dateien mit Hilfe von Betriebssystembefehlen an einen Sicherungsort kopiert. Dieser Sicherungsmechanismus, auch häufig COLD BACKUP genannt, setzt voraus, dass die Datenbank ordnungsgemäß heruntergefahren wurde. Oracle empfiehlt, möglichst jede Woche ein OFFLINE-Backup durchzuführen. Dies ist natürlich nur dann möglich, wenn Ihre Datenbank nicht 24 Stunden an 7 Tagen in der Woche geöffnet sein muss. Für diese Zwecke gibt es eine Reihe weiterer Sicherungsmethoden, die in den folgenden Kapiteln besprochen werden.

Stellen Sie sich vor, Sie haben eine Datenbank namens testdb29, welche sich im NOARCHIVELOG-Modus befindet. Die Control-Dateien haben Sie auf drei Platten verteilt, um im Crash noch eine Control-Datei zur Verfügung zu haben. Sie planen, ein OFFLINE-Backup jede Nacht durchzuführen. Die Sicherung soll in den Ordner /backup01 gespeichert werden. Von dort aus werden dann die darin enthaltenen Dateien auf Band gesichert.

Datenbankname: testdb29
Controldatei1     /oracle/oradata/testdb29/control01.ctl
Controldatei2     /control01/testdb29/control02.ctl
Controldatei3     /control02/testdb29/control03.ctl
Datendateien:     /oracle/oradata/testdb29/users01.dbf
                  /oracle/oradata/testdb29/system01.dbf
                  /oracle/oradata/testdb29/temp01.dbf
                  /oracle/oradata/testdb29/rbs01.dbf
                  /oracle/oradata/testdb29/idx01.dbf
Redo-Log-Dateien  /oracle/oradata/testdb29/redo01.log
                  /oracle/oradata/testdb29/redo02.log
                  /oracle/oradata/testdb29/redo03.log
Sicherungsort:   /backup01
In diesem Beispiel führen wir die notwendigen Operationen mit Hilfe von SQLPLUS durch.
  1. Fahren Sie die Datenbank ordnungsgemäß herunter. Sind noch Benutzer mit der Datenbank verbunden, so wartet SHUTDOWN NORMAL natürlich so lange, bis diese sich abgemeldet haben. Wenn Sie dies vermeiden wollen, so fahren Sie die Datenbank zuerst mit SHUTDOWN IMMEDIATE herunter und anschließend starten Sie die Datenbank mit STARTUP RESTRICT. Jetzt können Sie die Datenbank problemlos wieder mit SHUTDOWN NORMAL herunterfahren. Geben Sie einfach nur SHUTDOWN ein, so wird als Standardwert NORMAL angenommen.
  2. Kopieren Sie die Dateien (Datendateien, Controldateien und Redo-Log-Dateien) in den Ordner /backup01.
  3. Starten Sie die Datenbank normal mit STARTUP NORMAL.
Genau genommen ist es ausreichend, wenn Sie eine Control-Datei sichern. Ausschlaggebend hierfür ist der Fakt, dass die Controldateien identisch sind und nur aus Fehlertoleranzgründen redundant gehalten werden.

Natürlich ist es für einen Administrator nicht üblich jede Nacht die Sicherung manuell durchzuführen. Aus diesem Grunde wird an dieser Stelle das oben beschriebene Beispiel mit Hilfe eines Skriptes durchgeführt, welches automatisch jede Nacht gegen 22:00 Uhr ausgeführt wird. Als Basis der Automatisierung wird eine Shell-Script-Datei namens cold-backup.sh erzeugt.

# cold-backup.sh
sqlplus "sys/sys@testdb29 as sysdba" @~/sql-scripte/shutdown.sql
cp /oracle/oradata/testdb29/* /backup01
cp /control01/test/control02.ctl /backup01
cp /control02/test/control03.ctl /backup01
sqlplus "sys/sys@testdb29 as sysdba" @~/sql-scripte/startup.sql
Dieses Script ruft SQLPLUS mit der Parameterdatei shutdown.sql auf.
shutdown immediate
startup restrict
shutdown normal
exit
Diese Parameterdatei shutdown.sql fährt die Datenbank mit der Option IMMEDIATE herunter und anschließend wird die Datenbank normal mit der Einschränkung RESTRICT gestartet und normal heruntergefahren. Nun wird SQLPLUS durch den Befehl exit beendet und die Abarbeitung der Befehle in der cold-backup.sh fortgeführt. Es folgen die eigentlichen Copy-Befehle, gefolgt vom abschließenden Aufruf von SQLPLUS mit der Parameterdatei startup.sql.
startup
exit
Diese Parameterdatei erledigt nichts weiter als das erneute Hochfahren der Datenbank.


OFFLINE-Recovery - NOARCHIVELOG

Bei Beschädigung einer oder mehrerer Datendateien bzw. der gesamten Datenbank kann nur die komplette Datenbank wiederhergestellt werden. Alle Änderungen, die nach der letzten Sicherung durchgeführt wurden, sind nicht wiederherstellbar.

Fall 1

Nehmen wir einmal an, dass sich alle Transaktionen seit dem letzten Cold-Backup noch in den aktuellen Online-Redo-Logs befinden. Dass heißt, alle notwendigen Informationen für das Herstellen des Zustandes zum Zeitpunkt des Beschädigung sind noch im aktuellen Online-Redo-Log vorhanden. Wenn Sie wissen wollen, welche der Online-Redo-Log-Dateien die aktuelle Online-Redo-Log-Datei ist, so finden Sie das über folgende Abfrage heraus:
select v1.status,v1.sequence#,v1.first_change#,v2.member
  from v$log v1,v$logfile v2 where v1.group# = v2.group#
;
STATUS  SEQUENCE# FIRST_CHANGE# MEMBER
------------------------------------------------------------------
INACTIVE      232        401561 /oracle/oradata/testdb29/redo01.log
CURRENT       233        401562 /oracle/oradata/testdb29/redo02.log
INACTIVE      231        400998 /oracle/oradata/testdb29/redo03.log
In unserem Beispiel ist die Datei redo02.log die aktuelle Online-Redo-Log-Datei.

Wir wollen nun den oben beschriebenen Vorgang testen. Die Datenbank muss nun zuerst einmal durch ein Cold Backup gesichert werden. Nun wird eine neue Tabelle namens big im Tabelspace users erzeugt, ein Datensatz eingefügt und mit COMMIT abgeschlossen. Die Transaktion ist demnach beendet und der Datensatz befindet sich (natürlich erst nach dem Checkpoint) irgendwo in der Datei /oracle/oradata/testdb29/users01.dbf (da der Tablespace users nur aus dieser Datei besteht).

create table big(s1 int) tablespace users;
insert into big values(1);
commit;
Angenommen die Datei users01.dbf wird beschädigt und Sie ersetzen diese durch deren Sicherungsdatei. Die Tabelle big samt Inhalt befindet sich selbstverständlich nicht in dieser Datei, da die Tabelle big zum Zeitpunkt der Sicherung noch nicht existierte. Alle notwendigen Informationen für ein Rollforward befinden sich jedoch im aktuellen Online-Redo-Log (falls kein Log-Switch erfolgte) - und genau das machen wir uns nunmehr zu Nutze.

Als erstes fahren wir die Instanz herunter und kopieren die gesicherte Datei users01.dbf nach /oracle/oradata/testdb29. Nun fahren Sie die Instanz normal hoch.

shutdown abort;
host
cp /backup01/users01.dbf /oracle/oradata/testdb29/
exit
startup;
...
Datenbank mit Mount angeschlossen.
ORA-01113: Für Datei '3' ist eine Datenträger-Recovery notwendig
ORA-01110: Datendatei 3: '/oracle/oradata/testdb29/users01.dbf'
Da die eben wiederhergestellte Datei users01.dbf nicht die aktuelle Version der Datei ist, sondern lediglich eine wiederhergestellte Sicherungskopie, ist ein Datenträger-Recovery notwendig. Da sich aber alle notwendigen Informationen im aktuellen Online-Redo-Log befinden, ist dies kein Problem. Die nach der Sicherung erstellte Tabelle ist selbstverständlich wieder da.
recover datafilfe '/oracle/oradata/testdb29/users01.dbf';
select * from big;
       S1
---------
        1


Fall 2

Berechtigterweise können Sie sich nun die Frage stellen, was passiert, wenn die Veränderungen, die nach dem Cold Backup durchgeführt wurden, sich zwar nicht in der aktuellen Online-Redo-Log-Datei befinden, sondern in einer der anderen Online-Redo-Log-Dateien. Lassen Sie uns diesen Fall daher einmal durchspielen.

Hierfür ist es notwendig, dass Sie als erstes die Tabelle big löschen und danach ein Cold Backup durchführen (für das Cold Backup können Sie am besten das erstellte Skript benutzen). Als nächstes müssen Sie herausfinden, welches Online-Redo-Log die aktuelle Online-Redo-Log-Datei darstellt.

select v1.status,v1.sequence#,v1.first_change#,v2.member
  from v$log v1,v$logfile v2 where v1.group# = v2.group#
;
STATUS  SEQUENCE# FIRST_CHANGE# MEMBER
------------------------------------------------------------------
INACTIVE      232        401561 /oracle/oradata/testdb29/redo01.log
INACTIVE      233        401562 /oracle/oradata/testdb29/redo02.log
CURRENT       234        401564 /oracle/oradata/testdb29/redo03.log
Nehmen wir an, dass im Augenblick die Transaktionen in der Online-Redo-Log-Datei redo03.log mit der LSN 234 gespeichert werden. Nun erstellen Sie die Tabelle big erneut und führen einen oder zwei Log-Switches durch.
create table big(s1 int) tablespace users;
insert into big values(1);
commit;
alter system switch logfile;
alter system switch logfile;
Dadurch befindet sich die Transaktion nicht mehr im aktuellen Online-Redo-Log, sondern in einem der beiden anderen Online-Redo-Logs.
select v1.status,v1.sequence#,v1.first_change#,v2.member
  from v$log v1,v$logfile v2 where v1.group# = v2.group#
;
STATUS  SEQUENCE# FIRST_CHANGE# MEMBER
------------------------------------------------------------------
INACTIVE      235        422305 /oracle/oradata/testdb29/redo01.log
CURRENT       236        422306 /oracle/oradata/testdb29/redo02.log
INACTIVE      234        421564 /oracle/oradata/testdb29/redo03.log
Nehmen wir an, dassdie LSN 234 noch vorhanden ist. Demnach ist auch noch die Transaktion vorhanden und eine Wiederherstellung sollte möglich sein.

Wie im oberen Beispiel nehmen wir an, die Datei users01.dbf wird beschädigt und Sie ersetzen diese durch deren Sicherungsdatei. Die Tabelle big samt Inhalt befindet sich selbstverständlich nicht in dieser Datei, da die Tabelle big zum Zeitpunkt der Sicherung noch nicht existierte. Alle notwendigen Informationen für ein Rollforward befinden sich jedoch in einer der Online-Redo-Log-Dateien (nicht jedoch in der aktuellen Online-Redo-Log-Datei) und genau das machen wir uns nunmehr zu Nutze.

Als erstes fahren wir die Instanz herunter und kopieren die gesicherte Datei users01.dbf nach /oracle/oradata/testdb29. Nun fahren Sie die Instanz normal hoch.

shutdown abort;
host
cp /backup01/users01.dbf /oracle/oradata/testdb29/
exit
startup;
...
Datenbank mit Mount angeschlossen.
ORA-01113: Für Datei '3' ist eine Datenträger-Recovery notwendig
ORA-01110: Datendatei 3: '/oracle/oradata/testdb29/users01.dbf'
Laut Ausgabe ist für die Datei 3 ein Datenträger-Recovery notwendig. Alle notwendigen Transaktionen befinden sich in der Online-Redo-Log-Datei mit der LSN 234, die noch vorhanden ist (redo03.log).
recover datafilfe '/oracle/oradata/testdb29/users01.dbf';
select * from big;
       S1
---------
        1
Ale Ergebnis zeigt sich hier, dass bei Vorhandensein der notwendigen Transaktionsdaten eine Wiederherstellung auch im NOARCHIVELOG möglich ist.

Fall 3

Abschließend steht natürlich die Frage im Raum, was im Falle eines Nichtvorhandenseins der notwendigen Transaktionen passiert. Um diesen Fall zu testen, müssen lediglich mindestens 3 Log-Switches erfolgen. Somit wird bei drei Log-Gruppen die entsprechenden Transaktionen in jedem Fall überschrieben bzw. als überschreibbar markiert. Führen wir dieses Scenario nun kurz durch.

Als initialer Schritt wird wiederum die Tabelle big gelöscht (um den Ursprungszustand wieder herzustellen) und ein Cold-Backup erzeugt. Nun müssen Sie wieder herausfinden, welches Online-Redo-Log die aktuelle Online-Redo-Log-Datei darstellt. Hierfür können wir wieder die oben beschrieben Abfrage benutzen.

select v1.status,v1.sequence#,v1.first_change#,v2.member
  from v$log v1,v$logfile v2 where v1.group# = v2.group#
;
STATUS  SEQUENCE# FIRST_CHANGE# MEMBER
------------------------------------------------------------------
INACTIVE      235        422305 /oracle/oradata/testdb29/redo01.log
INACTIVE      236        422306 /oracle/oradata/testdb29/redo02.log
CURRENT       237        442308 /oracle/oradata/testdb29/redo03.log
Angenommen im Augenblick werden die Transaktionen in der Online-Redo-Log-Date redo03.log mit der LSN 237 gespeichert. Nun erstellen Sie die Tabelle big erneut, fügen einen Datensatz hinzu und führen anschließend drei Log-Switches durch.
create table big(s1 int) tablespace users;
insert into big values(1);
commit;
alter system switch logfile;
alter system switch logfile;
alter system switch logfile;
Dadurch befindet sich die Transaktion weder im aktuellen Online-Redo-Log, noch in einem der beiden anderen Online-Redo-Logs. In der unten ausgeführten Abfrage ist zu erkennen, dass die LSN 237 nicht mehr vorhanden ist, die Transaktion also nicht mehr verfügbar ist.
select v1.status,v1.sequence#,v1.first_change#,v2.member
  from v$log v1,v$logfile v2 where v1.group# = v2.group#
;
STATUS  SEQUENCE# FIRST_CHANGE# MEMBER
------------------------------------------------------------------
INACTIVE      238        443218 /oracle/oradata/testdb29/redo01.log
INACTIVE      239        443219 /oracle/oradata/testdb29/redo02.log
CURRENT       240        443220 /oracle/oradata/testdb29/redo03.log
Wir nehmen nunmehr an, die Datei users01.dbf wird beschädigt und Sie ersetzen diese durch deren Sicherungsdatei. Alle notwendigen Informationen für ein Rollforward befinden sich jedoch nicht mehr in einer der Online-Redo-Log-Dateien.

Als erstes fahren wir die Instanz9 herunter und kopieren die gesicherte Datei users01.dbf nach /oracle/oradata/testdb29. Nun fahren Sie die Instanz normal hoch.

shutdown abort;
host
cp /backup01/users01.dbf /oracle/oradata/testdb29/
exit
startup;
...
Datenbank mit Mount angeschlossen.
ORA-01113: Für Datei '3' ist eine Datenträger-Recovery notwendig
ORA-01110: Datendatei 3: '/oracle/oradata/testdb29/users01.dbf'
Wenn wir nun probieren, ein Datenträger-Recovery durchzuführen, so fragt Oracle nach der entsprechenden Datei, in der die Transaktionen drinstehen, in diesem Fall nach der Dateien mit der LSN 237. Da diese jedoch nicht mehr vorhanden ist bzw. eine andere LSN hat, schlägt ein Recovery fehl.
recover datafilfe '3';
...
Log angeben: {<RET=suggested | filename | AUTO | Cancel}
Die einzige Möglichkeit ist nunmehr ein vollständiges Wiederherstellen der Datenbank unter Verlust der Tabelle big.

Fall 4

In unserem vierten Fall beschäftigen wir uns mit einer ganz neuen Idee. Nehmen wir an, Sie hätten Ihre Datenbank Sonntag 20:00 Uhr mit Hilfe eines Cold Backups gesichert. Weiterhin nehmen wir an, dass Sie im Tablespace users eine sehr wichtige Tabelle mit sehr wichtigen Daten am Montag 10:00 Uhr erstellt haben.

Unglücklicherweise befinden sich diese Änderungen nicht mehr in den Online-Redo-Log-Dateien, so dass eine der weiter oben beschriebenen Methoden hier leider nicht in Frage kommt. Nun wird die Datei temp01.dbf beschädigt und die Datenbank muss wiederhergestellt werden.

Da sich die Transaktionen nicht mehr in den Online-Redo-Log-Dateien befinden, ist zuerst einmal von einer kompletten Wiederherstellung auszugehen. Dies würde jedoch einen Verlust der wichtigen Daten vom Montag 10:00 Uhr bedeuten. Daher ist es möglich, hier einen anderen Weg zu wählen. Da sich im Tablespace temp keine wichtigen Daten befinden, kann dieser gelöscht und neu erzeugt werden.

Um dieses Scenario einmal genauer zu betrachten, legen wir wieder die Datenbank testdb29 aus dem vorigen Kapiteln zugrunde. Voraussetzung ist wiederum, dass ein Cold Backup (angenommen Sonntag 22:00 Uhr) dieser Datenbank existiert. Nun (angenommen Montag 10:00 Uhr) erstellen wir die wichtige Datei big und füllen diese mit Datensätzen. Leider wird die Datei temp01.dbf im Laufe des Montags beschädigt. Ein erneutes Hochfahren der Instanz scheitert demzufolge. Sie können die beschädigte Datei, die das Öffnen der Datenbank verhindert, mit der Anweisung

ALTER DATABASE DATAFILE datafilename OFFLINE DROP;
löschen, anschließend die Datenbank öffnen, den Tablespace löschen und danach den Tablespace neu erstellen. Nun können Sie ganz normal weiterarbeiten.

Zusammenfassung

Als Konsequenz des Cold Backup im NOARCHIVE-Log-Modus ergibt sich ein gravierender Nachteil: Es ist nicht möglich ist, alle Daten wiederherzustellen. Es ist im NOARCHIVE-Modus lediglich möglich, die Datenbank bis zum Zeitpunkt der Sicherung wiederherzustellen. Des weiteren ist es für viele Datenbanken nicht möglich, jede Nacht heruntergefahren zu werden. Als Beispiel seien hier nur die zahlreichen Datenbanken im Internet genannt.

Anmerkung: Vergessen Sie nicht, bei einem shutdown immediate den angemeldeten Benutzern eine Nachricht zukommen zu lassen, bevor Sie die Datenbank herunterfahren. Sie werden es Ihnen danken.


OFFLINE-Backup - ARCHIVELOG

Bei einer Offline-Sicherung im ArchiveLog-Modus können alle Daten wieder hergestellt werden. In den archivierten Redo-Log-Dateien befinden sich alle notwendigen Transaktionen.

Betrachten wir wieder die Datenbank testdb29. Diese Datenbank sollte sich im ArchiveLog-Modus befinden. Sie müssen die Datenbank hierfür lediglich herunterfahren und folgende Einträge in die init.ora vornehmen:

log_archive_start = true
log_archive_dest_1 = "location=/oracle/oradata/testdb29/archive"
log_archive_format = %%ORACLE_SID%%T%TS%S.ARC
Durch den ersten Eintrag wird der Hintergrundprozess Archiver, der die Online-Redo-Log-Dateien sichert, automatisch gestartet. Durch den zweiten Eintrag wird das Ziel angegeben, in das die Online-Redo-Log-Dateien gesichert werden sollen. Durch den dritten Eintrag wird lediglich das Format der gesicherten Online-Redo-Log-Dateien definiert.

Anschließend müssen Sie die Datenbank im Status MOUNT versetzen und den Modus in ArchiveLog ändern. Anschließend kann dann die Datenbank geöffnet werden.

ALTER DATABASE ARCHIVELOG; 
ALTER DATABASE OPEN;
Wir nehmen an, dass diese Datenbank testdb29 durch ein Offline-Backup ganz normal gesichert wurde. Der Sicherungsordner sei /backup01. Hier sollte sich nun eine Sicherung aller Datendateien, Controldateien und Online-Redo-Log-Dateien befinden. Nun erstellen wir eine Tabelle PRODUKT im Tablespace USERS und tragen dort zwei Beispielprodukte ein.
select v1.status,v1.sequence#,v1.first_change#,v2.member
  from v$log v1,v$logfile v2 where v1.group# = v2.group#
;
STATUS  SEQUENCE# FIRST_CHANGE# MEMBER
------------------------------------------------------------------
INACTIVE      160        563628 /oracle/oradata/testdb29/redo03.log
CURRENT       161        564809 /oracle/oradata/testdb29/redo02.log
INACTIVE      159        561580 /oracle/oradata/testdb29/redo01.log

create table produkt(nr int, productname char(10)) tablespace users;
insert into produkt values(1,'Milch');
insert into produkt values(2,'Käse');
commit;
alter system switch logfile;
Angenommen, dass sich die After-Images beider Produkte (also die Produkte selber) in der Online-Redo-Log-Datei mit der LSN 161 (current) befinden. Nach dem Hinzufügen wurde ein Log-Switch ausgeführt. Das bedeutet, dass die Online-Redo-Log-Datei mit der LSN 161 nicht mehr die aktuelle Online-Redo-Log-Datei ist. Nun fügen wir zwei weitere Produkte hinzu.
select v1.status,v1.sequence#,v1.first_change#,v2.member
  from v$log v1,v$logfile v2 where v1.group# = v2.group#
;
STATUS  SEQUENCE# FIRST_CHANGE# MEMBER
------------------------------------------------------------------
INACTIVE      160        563628 /oracle/oradata/testdb29/redo03.log
ACTIVE        161        564809 /oracle/oradata/testdb29/redo02.log
CURRENT       162        565003 /oracle/oradata/testdb29/redo01.log

insert into produkt values(3,'Butter');
insert into produkt values(4,'Kekse');
commit;
alter system switch logfile;
Angenommen, dass sich die After-Images dieser beiden Produkte in der Online-Redo-Log-Datei mit der LSN 162 befinden. Die ersten beiden Produkte sind natürlich weiterhin in der Online-Redo-Log-Datei mit der LSN 161. Nun fügen wir zwei weitere Produkte hinzu.
select v1.status,v1.sequence#,v1.first_change#,v2.member
  from v$log v1,v$logfile v2 where v1.group# = v2.group#
;
STATUS  SEQUENCE# FIRST_CHANGE# MEMBER
------------------------------------------------------------------
CURRENT       163        565008 /oracle/oradata/testdb29/redo03.log
INACTIVE      161        564809 /oracle/oradata/testdb29/redo02.log
INACTIVE      162        565003 /oracle/oradata/testdb29/redo01.log

insert into produkt values(5,'Waffeln');
insert into produkt values(6,'Brot');
commit;
alter system switch logfile;
Angenommen, dass sich die After-Images dieser beiden neuen Produkte in der Online-Redo-Log-Datei mit der LSN 163 befinden. Die ersten Produkte sind natürlich weiterhin in der Online-Redo-Log-Datei mit der LSN 161 bzw. in der Online-Redo-Log-Datei mit der LSN 162. Ausschnitt aus den Online-Redo-Log-Dateien
LSN 161   1  Milch
          2  Käse
LSN 162   3  Butter
          4  Kekse
LSN 163   5  Waffeln
          6  Brot
Nun fügen wir zwei weitere Produkte hinzu.
alter system switch logfile;
select v1.status,v1.sequence#,v1.first_change#,v2.member
  from v$log v1,v$logfile v2 where v1.group# = v2.group#
;
STATUS  SEQUENCE# FIRST_CHANGE# MEMBER
------------------------------------------------------------------
ACTIVE        163        565008 /oracle/oradata/testdb29/redo03.log
CURRENT       164        565013 /oracle/oradata/testdb29/redo02.log
INACTIVE      162        565003 /oracle/oradata/testdb29/redo01.log

insert into produkt values(7,'Honig');
insert into produkt values(8,'Marmelade');
commit;
alter system switch logfile;
Angenommen, dass sich die After-Images dieser beiden neuen Produkte in der Online-Redo-Log-Datei mit der LSN 164 befinden. Die ersten beiden Produkte, die sich in der Online-Redo-Log-Datei mit der LSN 161 befinden, sind jedoch nicht mehr verfügbar. Diese Online-Redo-Log-Datei wurde überschrieben. Da sich die Datenbank jedoch im Modus ARCHIVELOG befindet, wurden die nicht aktuellen Online-Redo-Log-Dateien durch den Hintergrundprozess Archiver bereits weggesichert. Sie müssten sich wohlbehalten in genau dem Ordner, den wir in der INIT-Datei als Parameter angegeben haben.
cd /oracle/oradata/testdb29/archive
ls -1
TESTT001S00163.ARC
TESTT001S00162.ARC
TESTT001S00161.ARC


OFFLINE-Recovery - ARCHIVELOG

Arbeitsschritte:
  1. Instanz herunterfahren
  2. Alle notwendigen Dateien vom Tape zurück kopieren.
  3. startup mount;
  4. recover automatic database;
    Wenn die Archive-Logs woanders liegen
    recover from '/backup/' database;
Sollten nun eine oder mehrere Dateien beschädigt sein, so ist eine vollständige Wiederherstellung problemlos möglich. Alle notwendigen Informationen befinden sich in den Online-Redo-Log-Dateien bzw. in den archivierten Redo-Log-Dateien. Wir werden nun den Verlust der Datendatei users01.dbf simulieren.
shutdown immediate;
host
rm /oracle/oradata/testdb29/users01.dbf
exit
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 stellen nun die Datendatei users01.dbf von der Sicherung wieder her und versuchen nun erneut, die Datenbank testdb29 zu öffnen.
host
cp /backup01/users01.dbf /oracle/oradata/testdb29/
exit
alter database open;
*
FEHLER in Zeile 1:
ORA-01113: Für Datei '3' ist eine Datenträger-Recovery notwendig
ORA-01110: Datendatei 3: '/oracle/oradata/testdb29/users01.dbf'
Wir müssen nun die Transaktionen, die seit der Sicherung durchgeführt wurden, erneut durchführen lassen. Dies wird durch ein Recovery erreicht. Da sich in unserem Fall die ganze Recovery-Aktion nur auf eine Datendatei bezieht, muss natürlich auch nur diese eine Datendatei durch ein Recovery wiederhergestellt werden. Für das Recovery der Datendatei users01.dbf benutzen Sie folgende Anweisung:
RECOVER DATAFILE '/oracle/oradata/testdb29/users01.dbf';
Oracle versucht nun zu ermitteln, welche Redo-Log-Dateien angewendet werden müssen. In unserem Falle sind es die Dateien mit den LSN 161, 162, 163 und 164. Die Redo-Log-Datei mit der LSN 161 befindet sich jedoch nicht mehr unter den Online-Redo-Log-Dateien. Sie wurde jedoch bereits archiviert.

Nun fragt Oracle: Log angeben. Hier können Sie entweder mit ENTER den Vorschlag von Oracle annehmen, eine eigene Datei angeben (wenn Sie es wirklich besser wissen), oder die Anweisung AUTO eingeben. AUTO bedeutet, dass Oracle selbständig sich die richtigen archivierten Redo-Log-Dateien heraussucht und die Datendatei wiederherstellt. Wie Sie in dem oberen Beispiel erkennen können, ist im Anschluss alles ordnungsgemäß wieder vorhanden.


ONLINE-Backup

In der Praxis finden Sie eine immer stärker anwachsende Anzahl von Datenbanken, die 24 Stunden am Tag und dies auch noch 7 Tage die Woche Online sein müssen. In diesem Fall ist es natürlich nicht möglich, die Datenbank für ein Cold Backup in regelmäßigen Abständen herunterzufahren. Für diesen Fall gibt es unter Oracle die Möglichkeit, ein Hot Backup, auch oft als Online-Backup bezeichnet, auszuführen. Als Voraussetzung hierfür muss sich die Datenbank im Modus ARCHIVELOG befinden.

Hot Backups werden Tablespace-bezogen durchgeführt. Zuerst wird der Tablespace für die Sicherung vorbereitet. Anschließend werden die Dateien des entsprechenden Tablespaces mit Hilfe eines Betriebssystembefehls gesichert und nach dem Sichern der beteiligten Dateien wird die Sicherung.

ALTER TABLESPACE users01 BEGIN BACKUP;
host
cp /oracle/oradata/testdb29/users01.dbf /backup01/ 
exit
ALTER TABLESPACE users01 END BACKUP
Sollten Sie versuchen, die entsprechenden Dateien ohne ALTER TABLESPACE BEGIN BACKUP und ALTER TABLESPACE END BACKUP zu sichern, sind diese gesicherten Dateien für eine Wiederherstellung unbrauchbar. Nachdem ein Tablespace mit ALTER TABLESPACE BEGIN BACKUP in den Hot Backup Modus versetzt wurde, ändert sich das interne Verhalten. Die erste gravierende Veränderung bezieht sich auf das Aufzeichnen der Änderungen in den Redo-Log-Dateien. Es wird jetzt nicht mehr lediglich ein After-Image des verändernden Datensatzes aufgezeichnet, sondern jeweils ein Before Image des gesamten Blockes (Oracle-Block - nicht Betriebssystem-Block!), in dem sich der veränderte Datensatz befindet. Desweiteren wird die SCN zu Beginn des Befehls ALTER TABLESPACE BEGIN BACKUP in den Headern der einzelnen Datendateien 'eingefroren', das heißt, bis zum Befehl ALTER TABLESPACE END BACKUP bleibt diese SCN identisch. Folglich befindet sich in der Sicherung der Datendateien in jedem Falle die SCN, die zu Beginn der Sicherung aktuell war. Diese Vorgehensweise ist notwendig, da Oracle nicht weiss, zu welchen Zeitpunkt das Betriebssystem den Block mit dem Header der Datendatei sichert. Würde die SCN während der Sicherung nicht eingefroren werden, so könnte die SCN in den Datendateien der Sicherung größer als die SCN sein, die zu Beginn von ALTER TABLESPACE BEGIN BACKUP aktuell war. Für das korrekte Anwenden der Redo-Log-Einträge ist es jedoch zwingend erforderlich, dass die SCN der gesicherten Datendateien der SCN zu Beginn der Sicherung entsprechen. Nun kommen wir zur zweiten wichtigen Änderung in der Arbeitsweise. In den Redo-Log-Einträgen werden gesamte Block-Images gespeichert. Warum?

Ein Oracle-Block ist in der Regel ein Vielfaches eines Betriebssystem-Blockes. Die Größe eines Oracle-Blockes wird in der entsprechenden INI-Datei durch den Parameter DB_BLOCK_SIZE (z. B. 8192) festgelegt. Gebräuchliche Werte liegen zwischen 2K und 8k. Wenn das Betriebssystem aber mit einer Blockgröße von 2048 Byte arbeitet, so werden beim Sichern der Datendateien jeweils Blöcke von 2048 Byte gesichert. Ein Oracle-Block wird also nicht als Ganzes zur gleichen Zeit gesichert, sondern die Betriebssystemblöcke können zu verschiedenen Zeiten durch das Betriebssystem gesichert werden. Es ist demnach auch möglich, das in der Sicherung ein Oracle-Block nicht konsistent ist. Nehmen wir hierfür folgendes Beispiel an:

8K entspricht einem Oracle-Block

1 Milch    1 DM   2K  1 BS Block
2 Käse     3 DM
3 Butter   5 DM

4 Brot     2 DM   2K  1 BS Block
5 Wurst    7 DM

6 Sekt     8 DM   2K  1 BS Block
7 Äpfel   11 DM

8 Trauben  9 DM   2K  1 BS Block
9 Grütze  12 DM

Sie sehen einen Oracle-Block bestehend aus 4 Betriebssystemblöcken. Angenommen gegen 12:00 Uhr soll dieser Block gesichert werden (natürlich im Zuge der Sicherung der gesamten Datendatei bzw. gesamten Datendateien des entsprechenden Tablespaces). Dieser Block gehört zur Datendatei usr02.dbf und diese wiederum zum Tablespace users2. Gegen 12:00 Uhr wird also dieser Tablespace in den Hot Backup Modus versetzt

alter tablespace users2 begin backup;
Gegen 12:01 wird der Betriebssystemblock gesichert. Dieser Betriebssystemblock sieht dann gesichert folgendermaßen aus:
1 Milch   1 DM     2K  1 BS Block
2 Käse    3 DM
3 Butter  5 DM
Gegen 12:02 Uhr wird der Preis aller Produkte um 100% erhöht:
UPDATE products SET unitprice=unitprice*2;
COMMIT;
In diesem Fall werden die entsprechenden Seiten in den Daten-Buffer geladen und entsprechen verändert. Dadurch werden diese Blöcke zu Dirty-Blocks und im Zuge des nächsten Checkpoints auf der Platte aktualisiert. Nehmen wir an, dass ein Checkpoint gegen 12:03 Uhr auftrat und die Dirty-Buffers zurück in die Datendateien geschrieben wurden. Folglich sieht der Oracle-Block 12:03 Uhr folgendermassen aus:
1 Milch    2 DM   2K  1 BS Block 
2 Käse     6 DM
3 Butter  10 DM

4 Brot     4 DM   2K  1 BS Block
5 Wurst   14 DM

6 Sekt    16 DM   2K  1 BS Block
7 Äpfel   22 DM

8 Trauben 19 DM   2K  1 BS Block
9 Grütze  24 DM
Gegen 12:04 Uhr sichert nun das Betriebssystem den zweiten, dritten und vierten Betriebssystemblock. Der gesicherte Oracle-Block würde zum Zeitpunkt 12:05 Uhr nun folgendermassen aussehen:
1 Milch    1 DM   2K  1 BS Block 
2 Käse     3 DM
3 Butter   5 DM

4 Brot     4 DM   2K  1 BS Block
5 Wurst   14 DM

6 Sekt    16 DM   2K  1 BS Block
7 Äpfel   22 DM

8 Trauben 19 DM   2K  1 BS Block
9 Grütze  24 DM
Der Oracle-Block ist in sich nicht mehr konistent. Ein Teil der Preise wurde verändert, ein anderer noch nicht. Hierbei spricht man allgemein von einem Block-Split. Bei einem Recovery würden wir vor einem Problem stehen. Aus genau diesem Grund wird in der Online-Redo-Log-Datei bei einer Veränderung ein Before-Image des Blockes aufgezeichnet, also ein Image mit den alten Preisen.

Wird nun die entsprechende Sicherung (mit teilweise gesplitteten Blöcken) wiederhergestellt, so ist die SCN ja immer noch die, die zum Zeitpunkt des ALTER TABLESPACE BEGIN BACKUP (in unserem Beispiel 100) aktuell war. Da die während der Sicherung veränderten Oracle-Blöcke in den Online-Redo-Log-Dateien stehen, können diese beim Wiederherstellen der Sicherung schnell die inkonsistenten Oracle-Blöcke ersetzen.

Nachdem die Sicherung der entsprechenden Datendateien beendet ist, wird der Hot Backup Modus durch ALTER TABLESPACE END BACKUP wieder aufgehoben. Nachdem der Hot Backup Modus aufgehoben wurde, wird die Checkpoint SCN in den Headern der einzelnen beteiligten Datendateien wieder auf den aktuellen Stand gesetzt und alles geht seinen gewohnten Gang weiter.

Die Konsequenz dieser Arbeitsweise ist natürlich, dass zwischen ALTER TABLESPACE BEGIN BACKUP und ALTER TABLESPACE END BACKUP der Log-Verkehr zunimmt, sprich die Redo-Log-Dateien nehmen an Größe stärker zu als sonst. Folglich sollte man das Hot Backup nur zu Zeiten geringer DML-Aktivität durchführen, also zu Zeiten, wo wenig eingefügt, geändert und gelöscht wird. Desweiteren sollten Sie jeden Tablespace einzeln sichern, um die Zeit, die der Tablespace sich im Hot-Backup-Mode befindet, zu minimieren.

Richtig:

ALTER TABLESPACE user BEGIN BACKUP;
 HOST;
 cp /oracle/oradata/testdb29/usr02.dbf /backup01/
 cp /oracle/oradata/testdb29/usr03.dbf /backup01/
 EXIT
ALTER TABLESPACE user END BACKUP;
ALTER TABLESPACE idx BEGIN BACKUP;
 HOST;
 cp /oracle/oradata/testdb29/idx02.dbf /backup01/
 cp /oracle/oradata/testdb29/idx03.dbf /backup01/
 EXIT
ALTER TABLESPACE idx END BACKUP;
Falsch:
ALTER TABLESPACE user BEGIN BACKUP;
ALTER TABLESPACE idx BEGIN BACKUP;
 HOST;
 cp /oracle/oradata/testdb29/usr02.dbf /backup01/
 cp /oracle/oradata/testdb29/usr03.dbf /backup01/
 cp /oracle/oradata/testdb29/idx02.dbf /backup01/
 cp /oracle/oradata/testdb29/idx03.dbf /backup01/
 EXIT
ALTER TABLESPACE user END BACKUP;
ALTER TABLESPACE idx END BACKUP;
Für das Wiederherstellen einer Sicherung benötigen Sie mindestens alle Redo-Log-Dateien, die zwischen ALTER TABLESPACE ... BEGIN BACKUP und ALTER TABLESPACE ... END BACKUP erzeugt wurden. Dies reicht aber dann auch nur für ein Incomplete Recovery. Für ein Complete Recovery benötigen Sie alle Redo-Log-Dateien von Beginn der Sicherung an.

Vorgehensweise beim Hot Backup:

  1. Finden Sie heraus, ob sich die Datenbank im ArchiveLog-Modus befindet.
    ARCHIVE LOG LIST;
    
    Falls sich die Datenbank noch nicht im ArchiveLog-Modus befindet, so wechseln Sie in den ArchiveLog-Modus. Hierbei muß die Datenbank gemountet sein:
    alter database mount:
    alter database archivelog;
    archive log start;
    alter database open;
    
  2. Da der gesamte Redo-Log-Verkehr für ein späteres Recovery notwendig ist, muß nun die Online-Redo-Log-Datei (LSN) ermittelt werden, in die aktuell geschrieben wird.
    archive log list;
    
    Angenommen, dass die aktuelle Log Sequenz die Nummer 3 ist. Das heisst, die LSN 3 ist die erste LSN, die für das spätere Wiederherstellen erforderlich ist.
  3. Nun versetzen Sie den Tablespace in den Hot Backup Mode.
    ALTER TABLESPACE users BEGIN BACKUP
    
  4. Jetzt sichern Sie die zu diesem Tablespace gehörenden Datendateien an den Sicherungsort.
  5. Nun deaktivieren Sie für den Tablespace den Hot Backup Mode
    ALTER TABLESPACE users END BACKUP
    
  6. Da der gesamte Redo-Log-Verkehr für ein späteres Recovery notwendig ist, muß nun die Online-Redo-Log-Datei (LSN) ermittelt werden, in die aktuell geschrieben wird.
    archive log list;
    
    Angenommen, dass die aktuelle Log Sequenz die Nummer 4 ist. Das heisst, die LSN 4 ist die letzte LSN, die für das spätere Wiederherstellen zwingend erforderlich ist. Für ein Complete Recovery sind natürlich alle Redo-Log-Dateien von LSN 3 beginnend, notwendig.
Anzeige welche Dateien im Backup-Modus sind:
select * from v$backup;


ONLINE-Recovery

Arbeitsschritte:
  1. Instanz herunterfahren
  2. Alle notwendigen Dateien vom Tape zurück kopieren.
  3. startup mount;
  4. recover automatic database;
    Wenn die Archive-Logs woanders liegen
    recover from '/backup/' database;
Die Wiederherstellung eines durch ein Hot-Backup gesicherten Tablespaces soll an einem Beispiel verdeutlicht werden. Nehmen wir an, Sie haben den Tablespace user2 bestehend aus den Dateien usr02.dbf und usr03.dbf mit Hilfe eines Hot Backups Sonntag 22:00 Uhr in den Ordner /backup01 gesichert. Nehmen wir weiterhin an, dass am Montag eine Tabelle namens products erzeugt wurde und in diese Tabelle im Laufe des Montags 1000 Datensätze eingegeben wurden. Diese 1000 eingefügten Datensätze haben zum Beispiel 3 Log Switches verursacht. Am Montag abend ist die Datei usr02.dbf beschädigt und muß wieder hergestellt werden. Um dieses Beispiel zu simulieren, können wir natürlich nicht einfach so 1000 Datensätze einfügen. Wir fügen einfach zu Testzwecken 10 Datensätze ein und machen jeweils nach drei Datensätzen einen manuellen Log-Switch.
  1. Als erstes ermitteln wir die erste LSN, die wir benötigen.
    archive log list;
    
    Angenommen, dass die erste LSN, ist die LSN 5.
  2. Als zweites führen wir die eigentliche Sicherung durch
    ALTER TABLESPACE user2 BEGIN BACKUP
    host
    cp /oracle/oradata/testdb29/usr02.dbf /backup01/
    exit
    ALTER TABLESPACE user2 END BACKUP
    
  3. Nun erstellen wir die Tabelle products im Tablespace user2 und fügen die ersten drei Datensätze ein.
    create table produkt(nr int, productname char(10)) tablespace users;
    insert into produkt values(1,'Milch');
    insert into produkt values(2,'Käse');
    insert into produkt values(3,'Käse');
    commit;
    alter system switch logfile;
    archive log list;
    
    Angenommen, dass die nächste zu archivierende Log-Sequenz die 6 ist, muß die LSN 5 schon archiviert worden sein. Im Archivierungsorder müsste diese Datei schon zu finden sein (arc00005.001). Die After-Images der drei eben eingefügten Datensätze befinden sich demnach in der Datei arc00005.001.
  4. Als viertes werden wir weitere 3 Datensätze einfügen und einen Log-Switch ausführen.
    insert into produkt values(4,'Brot');
    insert into produkt values(5,'Kekse');
    insert into produkt values(6,'Mehl');
    commit;
    alter system switch logfile;
    archive log list;
    
    Angenommen, dass die nächste zu archivierende Log-Sequenz die 7 ist, muß die LSN 6 schon archiviert worden sein. Im Archivierungsorder müsste diese Datei schon zu finden sein (arc00006.001). Die After-Images der drei eben eingefügten Datensätze befinden sich demnach in der Datei arc00006.001.
  5. Als fünftes werden wir die letzten 4 Datensätze einfügen und einen Log-Switch ausführen.
    insert into produkt values(7,'Tee');
    insert into produkt values(8,'Saft');
    insert into produkt values(9,'Nektar');
    insert into produkt values(10,'Obst');
    commit;
    alter system switch logfile;
    archive log list;
    
    Angenommen, dass die nächste zu archivierende Log-Sequenz die 8 ist, muß die LSN 7 schon archiviert worden sein. Im Archivierungsorder müsste diese Datei schon zu finden sein (arc00007.001). Die After-Images der drei eben eingefügten Datensätze befinden sich demnach in der Datei arc00007.001.
  6. Nun simulieren wir einen Crash der Datei usr2.dbf.
    shutdown immediate;
    host
    rm /oracle/oradata/testdb29/usr2.dbf
    exit
    
  7. Jetzt versuchen Sie, die Instanz wieder hochzufahren. Da die Datei usr02.dbf beschädigt ist, kann aber die Datenbank lediglich gemountet werden.
    startup;
    ...
    Datenbank mit MOUNT angeschlossen.
    ORA-01157: Datendatei 7 kann nicht identifiziert/gesperrt werden
               Siehe DBWR-Trace-Datei.
    ORA-01110: Datendatei 7: '/oracle/oradata/testdb29/users02.dbf'
    
  8. Nun wird die Datei usr02.dbf aus dem Ordner /backup01 wiederhergestellt. Anschließend versuchen wir, die Datenbank zu öffnen.
    alter database open;
    *
    Fehler in Zeile 1:
    ORA-01113: Für Datei '7' ist eine Datenträger-Recovery notwendig
    ORA-01110: Datendatei 7: '/oracle/oradata/testdb29/users02.dbf'
    
  9. Wir müssen also noch ein Datenträger-Recovery durchführen, um die Datenbank wieder wie gewohnt öffnen zu können
    RECOVER DATABASE testdb29;
    ALTER DATABASE OPEN;
    

BACKUP CONTROLFILE

Nachdem Sie eine neue Datendatei zu einem Tablespace hinzugefügt haben, sollten Sie sofort die Control-Datei sichern. Der Grund hierfür ist, dass im Fehlerfall bei Wiederherstellen der veralteten Control-Datei diese neue Datei nicht bekannt wäre.
ALTER DATABASE BACKUP CONTROLFILE TO 'control01.bkp';
Hierdurch wird die Controldatei in einer Binärdatei namens control01.bkp gesichert.


TO File

Backup von Control-Files
alter database backup controlfile to '/backup/control.bkt';
Recover
shutdown immediate;
-- Control-Dateien kopieren
startup mount;
recover database until cancel using backup control file;
-- Mit CANCEL abbrechen.
alter database open resetlogs;


TO TRACE

Das Vorhandensein einer aktuelle Version der Control-Datei ist einer der wichtigsten Faktoren bei einer erfolgreichen Wiederherstellung einer Datenbank. Wie sie wissen, kann man bestimmte Parameter (maxdatafiles, maxlogfiles etc.) nach dem Erstellen einer Datenbank eigentlich nicht mehr ändern. Nur beim Neuerstellen können Sie hierfür neue Werte angeben. Das Wort 'eigentlich' birgt jedoch in sich doch noch eine Möglichkeit, dies bei einer bestehenden Datenbank im Nachhinein zu ändern. Sie müssen lediglich die Control-Datei neu erstellen. Da die Syntax zum Neuerstellen der Control-Datei relativ umständlich ist, können Sie sich die aktuelle Control-Datei skripten lassen. Hierfür führen Sie lediglich folgende Anweisung aus:
alter database backup controlfile to trace;
Das erstellte Skript finden Sie in dem Ordner, der als USER_DUMP_DEST in der INI-Datei definiert wurde. In unserem Fall liegt die entsprechende Datei in /oracle/admin/testdb29/udump. In diesem Skript finden Sie die entsprechende CREATE CONTROLFILE-Anweisung. Folgende Schritte müssen Sie durchführen, um eine neue Control-Datei zu erstellen:
  1. Starten Sie die Datenbank im Modus NOMOUNT
  2. Führen Sie die CREATE CONTROLFILE Anweisung aus.
  3. Führen Sie gegebenenfalls ein Recover aus.
  4. Öffnen Sie die Datenbank.
Oracle empfielt, nach dem Neuerstellen einer Control-Datei eine vollständige Sicherung der Datenbank.


Erstellen einer neuen Datendatei

Sie sollten Sie auch eine neue Daten-Datei sofort sichern, um später im Fehlerfall die Datei wiederherstellen zu können. Nehmen wir an, Sie haben keine Sicherung von einer neu hinzugefügten Daten-Datei. Und wie soll es anders kommen, genau diese Datei geht verloren. Auch für diesen Fall bietet Oracle eine geeignete Methode an. Sie können einfach die Datei neu erstellen. Hierfür bietet Oracle folgenden Befehl:
ALTER DATABASE CREATE DATAFILE 'dateiname'
Nun müssen Sie nur noch ein Recovery durchführen, um den aktuellen Stand der Datei zu erhalten. Lassen Sie uns ein Beispiel durchspielen. Als Grundlage dient wiederum unsere Datenbank testdb29 mit dem Tablespace user2, bestehend aus den beiden Dateien usr02.dbf und usr03.dbf. Wir werden als erstes eine weitere dritte Datei usr04.dbf hinzufügen.
alter tablespace user2 
  add datafile '/oracle/oradata/testdb29/usr04.dbf' size 5m;
Anschließend werden wir in diesem Tablespace eine Tabelle erzeugen und dort einige Datensätze eintragen und einen Log-Switch erzwingen. Nun werden wir die Instanz herunterfahren, die Datei usr04.dbf löschen und versuchen, die Instanz wieder hochzufahren.
create table produkt(nr int, productname char(10)) tablespace users;
insert into produkt values(1,'Milch');
insert into produkt values(2,'Butter');
insert into produkt values(3,'Käse');
commit;
alter system switch logfile;
shutdown immediate;
host;
rm /oracle/oradata/testdb29/usr04.dbf
exit
startup;
...
Datenbank mit Mount angeschlossen.
ORA-01157: Datendatei 9 kann nicht identifiziert/gesperrt werden
           Siehe DBWR-Trace-Datei.
ORA-01110: Datendatei 9: '/oracle/oradata/testdb29/users04.dbf'
Wir sehen in diesem Beispiel, dass Oracle natürlich die beschädigte Datei usr04.dbf zum Öffnen benötigt. Hierfür können wir einfach die Datei erstellen und probieren, die Datenbank erneut zu öffnen.
alter database create datafile '/oracle/oradata/testdb29/users04.dbf';
alter database open;
*
FEHLER in Zeile 1:
ORA-01113: Für Datei '9' ist eine Datenträger-Recovery notwendig
ORA-01110: Datendatei 9: '/oracle/oradata/testdb29/users01.dbf'
Natürlich ist noch ein Datenträger-Recovery für die Datei users04.dbf notwendig. Hierfür müssen alle Redo-Log-Dateien seit Erstellen der beschädigten Datendatei vorhanden sein. Die notwendigen Transaktionen werden dann auf die neu erstellte Datendatei users04.dbf angewendet, so dass diese Datei dann den Stand der beschädigten Datei hat.
recover datafile '/oracle/oradata/testdb29/users04.dbf';
alter database open;
Woher weiß aber Oracle, wo die notwendigen anzuwendenden Transaktionen für die Datei beginnen? Oracle speichert in der Control-Datei die aktuelle SCN beim Erstellen einer Datei. Ab hier muss dann begonnen werden, die entsprechenden Transaktionen vorwärts zu rollen, um für die Datendatei den aktuellen Stand wiederherzustellen.

Hinweis: Diese Methode funktioniert nur für Datendateien, die erstellt wurden, nachdem die Datenbank in den ArchiveLog-Modus wechselte.

Recover-Möglichkeiten

Mit der Anweisung RECOVER werden Transaktionen auf wiederhergestellte Datendateien, Tablespaces bzw. ganze Datenbanken angewendet.
RECOVER DATAFILE datafilename;
RECOVER TABLESPACE tablespacename;
RECOVER DATABASE;
Sie können die RECOVER-Anweisung entweder mit SQLPLUS oder im RMAN durchführen.


Incomplete Recovery

Wenn bei der Wiederherstellung einige Daten nicht wiederhergestellt werden, nennt man dies eine unvollständige Wiederherstellung. Diese kann gewollt oder ungewollt auftreten. Löscht jemand um 20:10 Uhr eine wichtige Tabelle, so können Sie ein zeitbasierte Wiederherstellung durchführen. Diese müsste alles bis zum Zeitpunkt 20:09 Uhr wiederherstellen.

Eine ungewollte unvollständige Wiederherstellung könnte durchgeführt werden müssen, wenn Sie bemerken, dass bei der Wiederherstellung eine Redo-Log-Datei fehlt. Prinzipiell gibt es drei verschiedene unvollständige Wiederherstellungsmöglichkeiten

Nach dem unvollständigen Wiederherstellen der Datenbank sind die Online-Redo-Log-Dateien natürlich nicht mehr brauchbar. Die Datenbank muß mit
ALTER DATABASE OPEN RESETLOGS
geöffnet werden. Hierdurch werden die Online-Redo-Log-Dateien zurückgesetzt, die anschließend wieder benutzt werden können.

Zeit-basiert

Nehmen wir an, Sie führen ein Cold-Backup der Datenbank testdb29 am Sonntag 22:00 Uhr durch. Die Dateien werden in den Ordner /backup01 gesichert.
shutdown immediate;
host;
cp /oracle/oradata/testdb29/* /backup01
exit
Nehmen wir an, Sie fahren die Datenbank am Montag gegen 8:00 Uhr wieder hoch. Folgendes passiert dann in folgenden zeitlichen Abständen:
  1. Erzeugen der Tabelle products am Montag um 8:05 Uhr.
    create table produkt(nr int, productname char(10)) tablespace users;
    
  2. Einfügen des ersten Datensatzes am Montag um 8:10 Uhr
    insert into produkt values(1,'Milch');
    commit;
    
  3. Einfügen des zweiten Datensatzes am Montag um 8:15 Uhr
    insert into produkt values(2,'Käse');
    commit;
    
  4. Einfügen des dritten Datensatzes am Montag um 8:20 Uhr
    insert into produkt values(3,'Butter');
    commit;
    
  5. Löschen der Tabelle products am Montatg 8:30 Uhr.
    drop table produkt;
    
  6. Durchführen eines Log-Switches
    alter system switch logfile;
    
Nun bemerken Sie, dass die gelöschte Tabelle noch gebraucht wird. Sie müssen die Tabelle wieder herstellen. Als erstes stellen Sie die Datenbank von der letzten Sicherung wieder her.
shutdown immediate;
host;
cp /backup01/* /oracle/oradata/testdb29/
exit
Nun versuchen Sie die Instanz zu erneut hochzufahren und zu öffnen. Es ist ein Recovery notwendig. Wir müssen die Datenbank bis zum Zeitpunkt Montag 8:25 Uhr wiederherstellen. Hierfür führen Sie eine zeitbasierte Wiederherstellung durch
RECOVER DATABASE UNTIL TIME 03.02.2003 08:25:00
Anschließend öffnen Sie die Datenbank mit der Option RESETLOGS, um die Online-Redo-Logs zurückzusetzen.
ALTER DATABASE OPEN RESETLOGS
Die Tabelle mit den Produkten ist wieder da, da das Löschen der Tabelle erst nach 8:25:00 geschehen ist.

Cancel-basiert

Eine Cancel-basierte Wiederherstellung muss durchgeführt werden, wenn bei einer Wiederherstellung eine archivierte Redo-Datei fehlt. Es ist dann nunmehr möglich, bis zu dieser Datei wiederherzustellen und anschließend die Datenbank mit der Option RESETLOGS zu öffnen.

Wir wollen nun dieses Beispiel einmal praktisch umsetzen. Voraussetzung hierfür ist, dass sich die Datenbank im ArchiveLog-Modus befindet und der Archiver-Prozess läuft.

archive log list;
Im ersten Schritt führen wir eine vollständige Sicherung als Cold Backup durch
shutdown immediate;
host;
cp /oracle/oradata/testdb29/* /backup01/
exit
Im zweiten Schritt starten fahren wir die Instanz wieder hoch und schauen uns das aktuelle Log an. Wir erzeugen dann eine Tabelle mitarbeiter im Tablespace users und fügen dort zwei Datensätze ein. Diese Datensätz stehen demnach im Log Nummer 9.
startup;
archive log list;
create table mitarbeiter(MiNr int, MiName varchar2(30)) tablespace users;
insert into mitarbeiter values(1,'Anna');
insert into mitarbeiter values(2,'Berta');
commit;
Jetzt führen wir zwei Log-Switches durch.
alter system switch logfile;
alter system switch logfile;
archive log list;
Durch den Archiver-Prozess wurden folgende Logs gesichert.
ls -1
ARC00007.001
ARC00008.001
ARC00009.001
ARC00010.001
Wir fügen zwei Datensätze ein. Diese Datensätz stehen demnach im Log Nummer 11.
archive log list;
insert into mitarbeiter values(3,'Carla');
insert into mitarbeiter values(4,'Doris');
commit;
Jetzt führen wir zwei Log-Switches durch.
alter system switch logfile;
alter system switch logfile;
archive log list;
Durch den Archiver-Prozess wurden folgende Logs gesichert.
ARC00007.001
ARC00008.001
ARC00009.001
ARC00010.001
ARC00011.001
ARC00012.001
Wir fügen zwei wietere Datensätze ein. Diese Datensätz stehen demnach im Log Nummer 13.
archive log list;
insert into mitarbeiter values(5,'Emil');
insert into mitarbeiter values(6,'Frank');
commit;
Jetzt führen wir zwei Log-Switches durch.
alter system switch logfile;
alter system switch logfile;
archive log list;
Zusammengefasst stehen folgende Redo-Einträge in folgenden archivierten Logs.
Log Nummer  9   1 Anna  und 2 Berta
Log Nummer 11   3 Carla und 4 Doris
Log Nummer 13   5 Emil  und 6 Frank
Jetzt wird die Datei users01.dbf des Tablespace users beschädigt. Es muss eine Wiederherstellung erfolgen. Zu allem Schaden ist auch noch das archivierte Log arc00011.001 (mit der Carla und der Doris) verloren gegangen. Die Datenbank fährt nicht mehr ordnungsgemäß hoch.
shutdown immediate;
host;
rm /oracel/ora92/rdbms/ARC00011.001
rm /oracle/oradata/testdb29/users01.dbf
exit
startup;
...
Datenbank mit Mount angeschlossen.
ORA-01157: Datendatei 7 kann nicht identifiziert/gesperrt werden
           Siehe DBWR-Trace-Datei.
ORA-01110: Datendatei 7: '/oracle/oradata/testdb29/users01.dbf'
Wir versuchen nun, die Datei users01.dbf von der Offline-Sicherung wiederherzustellen und ein Recover durchzuführen. Bedenken Sie, dass in der users01.dbf zum Zeitpunkt der Offline-Sicherung die Tabelle mitarbeiter noch nicht existiert.
host;
cp /backup01/* /oracle/oradata/testdb29/
exit
recover datafile 7;
...
ORA-00289: Vorschlag: /oracel/ora92/rdbms/ARC00009.001
Log angeben: {<RET=suggested | filename | AUTO | Cancel}
auto
Wiederherstellung nicht mehr erforderlich.
...
ORA-00308: Archive-Log '/oracel/ora92/rdbms/ARC00011.001' 
  kann nicht geöffnet werden.
Oracle hat hier nach den archivierten Log-Dateien gefragt, die anzuwenden sind. Es wurde hierbei AUTO angegeben, um Oracle zu veranlassen, die archivierten Logs selbständig zu ermitteln und anzuwenden. Leider fehlt das archivierte Log arc00011.001 (mit unserer Carla und unserer Doris).

Versuchen wir ein Cancel-basiertes Recovery der Datenbank mit der Offline-Sicherung der Datei users01.dbf. Wir geben hier nicht AUTO ein, sondern bestätigen jedes archivierte LOG mit ENTER bis zum achivierten Log arc00011.001. Dort geben wir CANCEL ein, um die Sicherung anzubrechen.

host;
cp /backup01/* /oracle/oradata/testdb29/
exit
recover database until cancel;
...
Log angeben: {<RET=suggested | filename | AUTO | Cancel}
cancel
Wie wir leider feststellen müssen war das Recovery zwar erfolgreich, ein Öffnen der Datenbank mit der Option RESETLOGS zum Zurücksetzen der Online-Redo-Log-Dateien würde fehlschlagen, da die anderen Backup-Dateien nicht 'alt' genug sind.
alter database open resetlogs;
*
FEHLER in Zeile 1:
ORA-01152: Backup-Datei zum Wiederherstellen der Datei 1 
  war nicht alt genug.
Die Ironie des Schicksals ist es nun, die gesamte Datenbank von der letzten Sicherung wiederherzustellen und anschließend das Cancel-basierte Recovery durchzuführen. Hiermit verlieren wir leider nicht nur den Datensatz von Carla und Doris, sondern auch alle anderen Datesätze, die nach dem LOG 10 in andere Tabellen anderer Tablespaces eingegeben wurden und deren Dateien womöglich noch in Ordnung sind.

Übung Cold Backup im Noarchive-Log-Modus

Übungen siehe Seite [*].

Übung Cold Backup im Archive-Log-Modus

Übungen siehe Seite [*].

Übung Control File skripten / wiederherstellen

Übungen siehe Seite [*].
next Recovery Manager (RMAN)
up Fundamentals
previous Shared Server
  Contents   Index


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