Oracle Fehler ORA-01578

[Maexx77]

Hallo,

ich habe in einer Oracle 8.1 Datenbank einen defekten Datenblock.

Datei-Nr 2 Block Nr 220457

Ich habe mit

SELECT SEGMENT_TYPE,OWNER||'.'||SEGMENT_NAME
FROM DBA_EXTENTS
WHERE FILE_ID = 2 AND 220458 BETWEEN BLOCK_ID
AND BLOCK_ID+BLOCKS -1;

herausgefunden um welche Datenbank Tabelle es sich handelt.

Master.PHYS_DATEI

Nun will ich mit DBMS_Repair.check_object prüfen, was defekt ist.

Diese Befehl liefert allerdings KEINEN Fehler in der Tabelle.

Was mache ich nun? Wie kann ich jetzt FIX_CORRUPT_BLOCKS aufrufen?

Anmerkung: Eine Rücksicherung mit RMAN oder ähnliches ist leider keine Option.

Bin dankbar für jeden Hinweis.

Gruß Marcel

[Maexx77]

Ergänzung:

Der Fehler wird auch durch
ANALYZE TABLE master.PHYS_DATEI VALIDATE STRUCTURE;
bestätigt.

[Wernfried]

Neue Tabelle erzeugen, Daten aus der alten Tabelle einfügen (Insert oder Export/Import) und alte Tabelle droppen, neue Tabelle umbenennen damit sie wie die alte heisst.

Oracle 8 ist so alt, da weiss ich gar nicht ob man eine Tabelle umbenennen kann. Wenn nicht musst du erst eine Zwischentabelle erzeugen, Daten in diese kopieren, die defekte Tabelle droppen, eine neue Tabelle erzeugen und die Daten aus der Zwischentabelle wieder einfügen.

Gruss

[Maexx77]

Hallo Wernfried,

vielen Dank für deine Antwort. Ich muss allerdings gestehen, dass ich eher der SQL-Server -Admin bin.

Ich habe jetzt versucht mit SELECT * INTO Tabelle_Neu FROM Tabelle_Alt die Tabelle zu erzeugen und die Daten darin abzulegen. Die Syntax bei Oracle scheint aber wohl anders zu sein.

Kannst du mir sagen, wie ich das machen kann?

Darüber hinaus befürchte ich, dass ich die Daten nicht kopieren kann, da sogar ein SELECT COUNT(*) FROM PHYS_Datei auf einen Fehler läuft (Defekter Datenblock).

Dann wird der Kopierbefehl (wie er auch immer heißen mag) doch das gleiche Problem haben, oder?

Gruß Marcel

[Maexx77]

Hallo nochmal,

die habe den Kopierbefehl gefunden (Create table....)

Allerdings ist es jetzt wirklich so, wie ich es befürchtet hatte:

FEHLER in Zeile 1:
ORA-01578: ORACLE-Datenblock beschädigt (Datei Nr. 2, Block Nr. 220457)
ORA-01110: Datendatei 2: 'D:\ORADB\D3P\DATA\D3_DAT01.DAT'

Was kann ich jetzt noch machen???

[Christian Marquardt]

Ich würde erstmal feststellen,ob hier ein physikalischer Schaden in der Datei D3_DAT01.DAT vorliegt. Wenn ja, werden wohl alle Rettungsversuche vergeblich sein.

Einfach die Datei mal in einen Editor laden.

[Maexx77]

Das Laden gestaltet sich auf Grund der Größe doch was schwieriger. Aber: mit dem richtigen Tool geht's. Also scheint die Datei nicht defekt zu sein.

Kann ich den angeblich defekten Datenblock ausklammern?
Mit DBMS_REPAIR.fix_corrupt_blocks geht's nicht, da die Repair_Table ja leer ist.

Irgendwelche Ideen????

[Bernhard Geyer]

Das Laden gestaltet sich auf Grund der Größe doch was schwieriger. Aber: mit dem richtigen Tool geht's. Also scheint die Datei nicht defekt zu sein.

Nicht unbedingt. Es kanns schon sein das das OS bzw. das Festplatten-Bios noch rettbare Teile entsprechend an andere Stelle auf Festplatte verschoben hat.
Schau doch mal Windows-Ereignislog ob du entsprechende Meldungen über HW-Defekte vorliegen hast (wird leider von Windows ohne User-Rückmeldung über potentiellen Datenverlust einfach so gelogt)

[Maexx77]

Ok, aber wie komme ich an diese "rettbaren Teile"?
Und warum wird einmal gesagt, dass der Datenblock beschädigt ist, aber wenn ich reparieren will, wird gesagt, dass keine Fehler da sind?!?

[Wernfried]

Vielleicht kannst du mit diesem Statement herausfinden welche Zeilen in der Tabelle betroffen sind.

[highlight=sql]SELECT
DBMS_ROWID.ROWID_OBJECT(rowid) "OBJECT",
DBMS_ROWID.ROWID_RELATIVE_FNO(rowid) "FILE",
DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid) "BLOCK",
DBMS_ROWID.ROWID_ROW_NUMBER(rowid) "ROW"
FROM Master.PHYS_DATEI
WHERE DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid) = 220457
AND DBMS_ROWID.ROWID_RELATIVE_FNO(rowid) = 2[/highlight]

Beim Kopieren der Tabelle kannst du diese Zeilen dann auslassen.

Gruss

[Maexx77]

Klingt super (netter Ansatz!)

Aber leider lösen die Funktionen wohl den gleichen Fehler aus.

[Wernfried]

Dann musst du es Zeile für Zeile machen (könnte etwas länger dauern):

[highlight=sql]
DECLARE
Cursor curTab IS
SELECT ROWID as aRow, t.* FROM Master.PHYS_DATEI t;
cur curTab%ROWTYPE;
BEGIN
OPEN curTab;
LOOP
BEGIN
FETCH curTab INTO cur;
EXCEPTION
WHEN OTHERS THEN
NULL; -- oder irgendeine Fehlermeldung ausgeben
END;
INSERT INTO Neue_Tabelle...;
EXIT WHEN curTab%NOTFOUND;
END LOOP;
CLOSE curTab;
END;
[/highlight]



Gruss

[Maexx77]

Super, vielen dank für die Mühe, die du dir mit mir machst!!!! Danke.

Ich habe das Statement erst mal OHNE den Insert-Befehl ausgeführt (zum testen)

'Schrittweise kopieren....
DECLARE
Cursor curTab IS
SELECT ROWID AS aRow, t.* FROM Master.PHYS_DATEI t;
cur curTab%ROWTYPE;
BEGIN
OPEN curTab;
LOOP
BEGIN
FETCH curTab INTO cur;
EXCEPTION
WHEN OTHERS THEN
NULL; -- oder irgendeine Fehlermeldung ausgeben
END;

EXIT WHEN curTab%NOTFOUND;
END LOOP;
CLOSE curTab;
END;
/

Und wen wundert es, ich bekommen wieder mal einen Fehler:

DECLARE
*
FEHLER in Zeile 1:
ORA-03113: end-of-file on communication channel

Ein Netzwerk-Problem scheint das nicht zu sein, da SQLPlus auf dem Server ausgeführt wird.
Liegt das jetzt daran, dass ich den Insert-Befehl rausgenommen habe?

Noch mal zum Verständnis: Den Insert-Befehl muss ich doch dann so bauen
insert into Master.Phys_datei_bak (Feld1, Feld2, .....) VALUES (cur.Feld1, cur.Feld2, ....)
Oder?

[Wernfried]

Lass mal die ROWID weg. Der Insert Befehl muss so sein wie du schreibst, das ist richtig.
Schreib das EXIT WHEN... mal direkt hinter den FETCH Befehl, u. U. haben wir hier eine Endlos-Schleife.

Gruss

[Maexx77]

SQL> DECLARE
2 Cursor curTab IS
3 SELECT t.* FROM Master.PHYS_DATEI t;
4 cur curTab%ROWTYPE;
5 BEGIN
6 OPEN curTab;
7 LOOP
8 BEGIN
9 FETCH curTab INTO cur;
10 EXIT WHEN curTab%NOTFOUND;
11 EXCEPTION
12 WHEN OTHERS THEN
13 NULL; -- oder irgendeine Fehlermeldung ausgeben
14 END;
15
16
17 END LOOP;
18 CLOSE curTab;
19 END;
20 /
DECLARE
*
FEHLER in Zeile 1:
ORA-03113: end-of-file on communication channel

Leider das gleiche....