Auswahl  

 

Oracle
DBA
4.x
29.06.18 (MP)
29.06.18 (MP)
DBA

Body

Sie haben vor Kurzem auf 11.2.0.2 umgestellt und auch schon einen Schreibzugriffsfehler in einer Datendatei gehabt? Dann haben Sie sich vielleicht gewundert, warum die gesamte Instanz abgestützt ist. Bislang wurde die betroffene Datei lediglich offline gesetzt, sofern es sich dabei nicht um eine SYSTEM- oder UNDO-Datendatei handelte.

Diese Änderung hängt mit einem versteckten (nicht dokumentierten) Parameter zusammen, namens "_datafile_write_errors_crash_instance". Dieser Parameter wurde in der Version 11.2.0.1 eingeführt, erhielt zunächst aber den Default-Wert FALSE. Damit hatte er keinerlei Auswirkung auf das bisherige Verhalten bei (Schreib-)Fehlern in den Datendateien: Wurde solch ein Fehler von Oracle entdeckt (z.B. im Rahmen eines Checkpoints), dann wurde die Datei (bei eingeschalteter Archivierung) automatisch offline gesetzt. Der Versuch, Daten aus dieser Datei aufzurufen wird mit folgender Fehlermeldung quittiert:

FEHLER in Zeile 1:
ORA-00376: Datei 4 kann zur Zeit nicht gelesen werden
ORA-01110: Datendatei 4: 'C:\ORACLE\ORADATA\O11G2\USERS01.DBF'


In der Alert-Datei findet man dazu folgenden Eintrag:

Mon Nov 21 15:12:20 2011
Errors in file c:\oracle\diag\rdbms\o11g2\o11g2\trace\o11g2_ckpt_556.trc:
ORA-01171: Datendatei 4 wird offline gesetzt wegen Checkpoint-Fehler im Header
ORA-01110: Datendatei 4: 'C:\ORACLE\ORADATA\O11G2\USERS01.DBF'
ORA-01115: EA-Fehler beim Lesen von Block aus Datei 4 (Block Nr. 1)
ORA-27072: Datei-I/O-Fehler
OSD-04006: ReadFile()-Fehler, aus Datei kann nicht gelesen werden
O/S-Error: (OS 38) Ende der Datei (EOF) erreicht.
Mon Nov 21 15:12:20 2011
Checker run found 1 new persistent data failures
Mon Nov 21 15:18:03 2011
Errors in file c:\oracle\diag\rdbms\o11g2\o11g2\trace\o11g2_m000_3532.trc:
ORA-01135: Datei 4, auf die durch DML/Abfrage zugegriffen wurde, ist offline
ORA-01110: Datendatei 4: 'C:\ORACLE\ORADATA\O11G2\USERS01.DBF'


Ab Version 11.2.0.2 steht der Parameter nun standardmäßig auf TRUE und bewirkt einen Instanzabsturz im Falle eines Schreibfehlers für eine - aus Oracle Sicht - weniger wichtige Datendatei. In der Alert-Datei findet sich nun folgender Eintrag:

Mon Nov 21 15:39:21 2011
Read of datafile 'C:\ORACLE\ORADATA\O11G2\USERS01.DBF' (fno 4) header failed with ORA-01210
Hex dump of (file 4, block 1) in trace file c:\oracle\diag\rdbms\o11g2\o11g2\trace\o11g2_ckpt_556.trc
Corrupt block relative dba: 0x01000001 (file 4, block 1)
Completely zero block found during datafile header read
Rereading datafile 4 header failed with ORA-01210
Hex dump of (file 4, block 1) in trace file c:\oracle\diag\rdbms\o11g2\o11g2\trace\o11g2_ckpt_556.trc
Corrupt block relative dba: 0x01000001 (file 4, block 1)
Completely zero block found during datafile header read
Errors in file c:\oracle\diag\rdbms\o11g2\o11g2\trace\o11g2_ckpt_556.trc:
ORA-63999: Datenträgerfehler bei Datendatei
ORA-01122: Überprüfung von Datenbank-Datei 4 nicht erfolgreich
ORA-01110: Datendatei 4: 'C:\ORACLE\ORADATA\MYO11G2\USERS01.DBF'
ORA-01210: Datendatei-Header hat physikalischen Fehler
Errors in file c:\oracle\diag\rdbms\o11g2\o11g2\trace\o11g2_ckpt_556.trc:
ORA-63999: Datenträgerfehler bei Datendatei
ORA-01122: Überprüfung von Datenbank-Datei 4 nicht erfolgreich
ORA-01110: Datendatei 4: 'C:\ORACLE\ORADATA\O11G2\USERS01.DBF'
ORA-01210: Datendatei-Header hat physikalischen Fehler
CKPT (ospid: 556): terminating the instance due to error 63999
Instance terminated by CKPT, pid = 556

 

ABFRAGE DES VERSTECKTEN PARAMETERS


Da es sich bei diesem Parameter um einen versteckten Parameter handelt, müssen Sie leider etwas umständlich vorgehen, um an die aktuelle Einstellung zu kommen:

CONN / as sysdba
col KSPPINM FORMAT A40
col KSPPSTVL FORMAT A8
col KSPPSTDF FORMAT A8
col KSPPDESC FORMAT A100
SELECT b.ksppinm, a.ksppstvl, a.ksppstdf, b.ksppdesc
  FROM sys.x$ksppi b, sys.x$ksppcv a
  WHERE a.indx = b.indx
    AND b.ksppinm = '_datafile_write_errors_crash_instance';
KSPPINM                                  KSPPSTVL KSPPSTDF
---------------------------------------- -------- --------
KSPPDESC
-------------------------------------------
_datafile_write_errors_crash_instance    TRUE     TRUE     
datafile write errors always crash instance

 

Die Spalte KSPPSTVL gibt dabei den aktuellen Wert des Parameters aus und die Spalte KSPPTDF enthält, ob der Parameter explizit gesetzt worden ist (FALSE) oder noch seinen Default-Wert (TRUE) besitzt.

 

ÄNDERUNG DES VERSTECKTEN PARAMETERS


Falls Sie den Parameter wieder auf FALSE setzen möchten, gehen Sie folgendermaßen vor:

ALTER SYSTEM SET "_datafile_write_errors_crash_instance" = FALSE;

Natürlich können Sie bereits in Version 11.2.0.1 den Parameter auf TRUE setzen, falls Sie hier ebenfalls das geänderte (Absturz-)Verhalten "erleben" möchten.

 

ABSCHLUSSBEMERKUNG


Bleibt am Schluss die Frage, "Warum dieses neue Verhalten?". Aus dem Blickwinkel "Hochverfügbarkeit" heraus betrachtet, stuft man dieses neue Feature zunächst als äußerst fragwürdig ein: wo ist meine Verfügbarkeit geblieben, wenn bei jedem Schreibfehler in eine Datendatei sofort ein Instanzabsturz erfolgt. Ist es nicht besser, wenn nur die betroffene Datei aus dem Betrieb heraus genommen wird, also offline gesetzt wird, aber das System weiter verfügbar ist? Eigentlich ja, allerdings hat es teilweise länger gedauert, bis der Fehler schließlich bemerkt wurde und es hat immer das Eingreifen des DBAs erfordert, da ein Media Recovery notwendig war.

Heutzutage ist ein Großteil der I/O Fehler nur vorübergehender Natur und lässt sich durch einen Neustart des Systems oder durch die modernen Plattensysteme (SAN, RAID etc.) beheben. Befindet sich die betroffene Instanz zudem in einer RAC- oder Data Guard Umgebung, dann kann durch einen Absturz das automatische Umschalten erreicht werden und somit eine wesentlich höhere Verfügbarkeit realisiert werden. Ein menschliches Eingreifen ist dabei in aller Regel auch nicht mehr erforderlich.

Oracle sagt also, dass ein Offline-Setzen einer Datendatei durch einen I/O Fehler beim heutigen Stand der Technik und der oraclespezifischen Möglichkeiten nicht mehr zeitgemäß wäre.

Entscheiden muss letztendlich jeder DBA selbst, welchem Verhalten er mehr abgewinnen kann. Wichtig ist nur, dass er über die Neuerungen Bescheid weiß.

Weitere Tipps und Informationen erhalten Sie in unseren DBA Kursen.

Besuchen Sie uns doch bei einer unsere über 40 Oracle Schulungen in München - Unterhaching.