Als PDF Downloaden!

Verlust von Datendateien

Beim Verlust von Datendateien muss unterschieden werden, um welche Datei es sich handelt.

Fall 1:

• Datei, die entweder zum Tablespace SYSTEM gehört bzw.
• Datei, die aktive UNDO-Segmente besitzt

Fall 2:

• Datei, die zu einem normalen Tablespace gehört (z. B. INDX, TOOLS, DATEN, USERS, ... )

Beispiel zu Fall 1:

• Die Instanz ist abgestürzt, weil der System-Tablespace nicht mehr verfügbar war
• Archivierung ist eingeschaltet
• Ein Backup des Tablespace vom Vortag ist vorhanden
• Alle archivierten Redo-Log-Dateien seit dem letzten Backup sind auch lückenlos vorhanden
• Die Instanz wird neu gestartet

CONNECT sys/<pwd> AS SYSDBA
STARTUP

ORACLE-Instance hochgefahren.
Total System Global Area  364904448 bytes
Fixed Size                  1296740 bytes
Variable Size             109053596 bytes
Database Buffers          247463936 bytes
Redo Buffers                7090176 bytes
Database mit Mount angeschlossen.

ORA-01157: cannot identify data file 1 - file not found
ORA-01110: data file 1: d:\oracle\oradata\o10g\system01.dbf

Lösung zu Fall 1:

Sie können zuerst prüfen, welche Datei von der Datenbank als defekt erkannt worden ist mit:

SELECT * FROM v$recover_file;

Spielen Sie das letzte Backup der Datei vom Tablespace SYSTEM wieder ein:

HOST copy c:\backup\system01.dbf d:\oracle\oradata\o10g\

Recovern Sie die Datenbank. Hier wird nur der Tablespace repariert, der defekt war:

recover database

oder benutzen Sie folgendes Kommando:

recover tablespace system

Je nachdem, wie viele archivierte Redo-Log-Dateien nach dem letzten Backup bereits erzeugt wurden, wird Ihnen jede notwendige Datei für die Reparatur vorgeschlagen z.B.:

ORA-00279: change 275337 generated at 12/02/02 15:32:19 needed for thread 1
ORA-00289: suggestion : c:\backup\arch_24.arc
ORA-00280: change 275337 for thread 1 is in sequence #24
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

Es stehen nun vier Alternativen zur Wahl:

1. <RET>  die vorgeschlagene Datei wird akzeptiert
2. filename  man gibt hier ein(en) alternativen Namen/Verzeichnis für die Datei an
3. AUTO  alle weiteren Dateien (inkl. der aktuellen) werden mit Return automatisch bestätigt.
4. CANCEL  der Recovery-Vorgang wird abgebrochen

Am schnellsten erfolgt die Wiederherstellung mit der Option AUTO.

Nach folgender Meldung ist das Recovery vollständig abgeschlossen:

Log applied.
Media recovery complete.

Nun kann die Datenbank geöffnet werden mit:

ALTER DATABASE OPEN;

Die Datenbank ist nun konsistent und wieder repariert. Die Benutzer können normal weiterarbeiten.

Beispiel zu Fall 2:

• Die Datendatei des Tablespace USERS ist beschädigt
• Archivierung ist eingeschaltet
• Ein Backup des Tablespace vom Vortag ist vorhanden
• Alle archivierten Redo-Log-Dateien seit dem letzten Backup sind lückenlos vorhanden
• Die Datenbank ist geöffnet

SELECT * FROM scott.emp;

SELECT * FROM scott.emp
                    *
FEHLER in Zeile 1:
ORA-01115: EA-Fehler beim Lesen von Block aus Datei 4 (Block Nr. 28)
ORA-01110: Datendatei 4: 'E:\ORACLE\ORADATA\ORCL\USERS01.DBF'
ORA-27091: I/O kann nicht in Queue gestellt werden
ORA-27070: Asynchrones Lesen/Schreiben nicht erfolgreich
OSD-04006: ReadFile()-Fehler, aus Datei kann nicht gelesen werden
O/S-Error: (OS 38) Ende der Datei (EOF) erreicht.

Lösung zu Fall 2:

Sie sollten zuerst wieder prüfen, welche Datei von der Datenbank als defekt erkannt worden ist mit:

SELECT * FROM v$recover_file;

Falls noch keine Zeile zurückkommt, führen Sie zuerst einen Checkpoint durch und selektieren Sie danach erneut v$recover_file. Die beschädigte Datei sollte nun offline sein:

ALTER SYSTEM CHECKPOINT;

SELECT * FROM v$recover_file;

FILE# ONLINE  ONLINE_ ERROR    
----- ------- ------- --------------
    4 OFFLINE OFFLINE FILE NOT FOUND

Wenn Sie nun erkannt haben, welche Datei beschädigt ist, spielen Sie das letzte Backup dieser Datei ein:

HOST copy c:\backup\users01.dbf e:\oracle\oradata\orcl\

Recovern Sie die zurückgesetzte Datei

recover datafile 4

oder benutzen Sie folgendes Kommando:

recover tablespace users

Hinweis: Der Recoverprozess läuft analog zu Fall 1

Setzen Sie den Tablespace zum Schluss wieder online:

ALTER TABLESPACE users ONLINE;

 

Suche