ORA-600

Im Alltag eines Oracle-DBAs oder -Entwicklers treten über kurz oder lang die berüchtigten „ORA-00600„-Fehler auf, die in etwa so sprechend sind wie die „Allgemeine Schutzverletzung“ unter Windows…

Umgang mit diesem Fehler

Als einzige Maßnahme gibt „oerr“ folgendes aus: „Melden Sie es als Bug [bei Oracle Support]“.

Dem Anwender stehen aber noch weitere Möglichkeiten offen: Wer Zugriff auf die Wissensbasis von Oracle hat („My Oracle Support“, früher „Metalink“), kann dort das „ORA-00600-Troubleshooting Tool“ und

  • anhand eines mit adrci erstellten IPS-Packages oder
  • anhand des zugehörigen Tracefiles und des Alert Logs

die Datenbank von Oracle Support nach passenden Dokumenten und Empfehlungen durchforsten lassen.

Wer kein Tracefile oder noch keinen Zugriff auf adrci (gibt’s erst ab 11g) hat, kann das ältere „ORA-600/ORA-7445 Error Look-up Tool“ aufrufen und

  • anhand des ersten Arguments der Fehlermeldung (in [])
  • oder anhand des Stack Dumps aus dem zugehörigen Tracefile

die Datenbank von Oracle Support nach passenden Dokumenten und Empfehlungen durchforsten lassen. Pfad und Name des zugehörigen Tracefiles werden bei der Fehlermeldung mit ausgegeben; daraus sind dann alle Zeilen zwischen

----- Call Stack Trace -----
und
----- End of Call Stack Trace -----

auszuschneiden und in den Browser einzufügen.

Wenn hier keine hinreichenden Informationen zu Ursache und Behebung gefunden werden, sollte unbedingt ein Service Request bei Oracle Support eröffnet werden. Vielleicht können Sie sich ja bald rühmen, einen neuen Bug entdeckt und damit allen Oracle-Anwendern geholfen zu haben. :-)

Gefahrenpotential

Diese Fehlermeldungen können auf Datenverluste hindeuten, müssen es aber nicht unbedingt. Nichtsdestotrotz sollte man das Auftreten eines „ORA-600“ oder „ORA-7445“ nicht auf die leichte Schulter nehmen und der Ursache auf den Grund gehen. Dies kann man anhand der Oracle-Wissensbasis (s.o.), entweder selbst oder mit Hilfe des zuständigen DBAs. Oder man eröffnet einen Service Request bei Oracle Support, um das Problem vom Hersteller selbst klären zu lassen.

Der kleine ORA-600-Laden

Hier entsteht ein loses Sammelsurium dieser Kuriositäten, zusammen mit einer Kurzbeschreibung des Szenarios sowie Links und/oder Lösungsansätzen.

ORA-600 [729] [56] [space leak]

Deutet auf einen Speicherverlust in der User Global Area (UGA) hin. Laut Oracle Support Note 31056.1 keine Gefahr von Datenverlust. Das zweite Argument gibt an, wie viele Bytes „verloren“ gegangen sind.

Note:403584.1 beschreibt die Hintergründe und den Umgang mit diesem Fehler, der ignoriert werden kann, wenn er während eines Logoffs auftritt und für den sogar eine Einstellung getroffen werden kann, ihn bis zu einer gewissen Schwelle gar nicht zu melden.

Konkret kam dieser Fehler in einer Umgebung vor, in der es aufgrund von zu knappem RAM und vielem Paging tatsächlich zu verschiedenen Problemen kam.

ORA-600 [1158]

Tauchte in einer DB der Version 11.2.0.4 auf – interessant ist dabei, dass laut Note 66387.1 nur Versionen bis 10.1 betroffen sein sollen.

Hierbei war der zu der betroffenen Session gehörende Prozess abgeraucht. Infolgedessen zeigte sich ein eigenartiges Szenario: Etliche Sessions wurden durch Locks blockiert, die von den Prozessen „DBW0“ und „SMON“ gehalten wurden! Hier half nur ein Beenden der betroffenen Sessions.

Die auslösende Session wurde von einer alten TOAD-Version (9.5) genutzt, die nicht gegen Oracle 11.2 zertifiziert ist. Ob das Auftreten des ORA-600 tatsächlich unmittelbar mit der TOAD-Version zusammenhängt, konnte noch nicht ermittelt bzw. nicht reproduziert werden.

ORA-600 [2663] [5]

„A description for this ORA-600 error is not yet published.“

Hintergrund: Eine Test-DB wurde als Klon einer anderen DB via Binärkopie erzeugt. Während des Hochfahrens kam dann die Fehlermeldung.

Ein Blick ins Tracefile gibt Aufschluss darüber, dass ein Rollback-Segment fehlerhaft ist. Dieses enthielt zum Zeitpunkt des Backups eine laufende Transaktion. Dies konnte passieren, da die Binärkopie angefertigt wurde, während die Quell-DB online war. Das Problem wurde durch eine erneute Kopie umgangen.

Ein ähnlicher Fall: „Stuck in No-Man’s Land: …

ORA-600 [4193] [a] [b]

Ein Unterschied zwischen Redo und Undo wurde festgestellt.

[a] enthält die Nummer des Undo Records

[b] enthält die Nummer des Redo Records

Mögliche Ursache: Fehler im Rollback-Segment ==> Recovery durchführen. Siehe Oracle Note 39282.1.

ORA-600 [15419]

Hierbei handelt es sich zunächst um einen generischen, schwerwiegenden PL/SQL Fehler. Aufgetaucht war er in einer speziellen Konstellation mit dem zweiten Fehler:

ORA-06553: PLS-801: internal error [pbjem_match – unknown/unimpl modKind]

während einer Debugging-Session mit dem SQL Developer. Hierbei handelt es sich um Bug 9085718, der Oracle 11.1.0.6 und 11.2.0.3 betrifft und erst in 12.1 gefixt sein soll.

Der Fehler tritt nicht immer auf; in meinem Fall war es ein etwas komplexeres ETL-Szenario mit Prozeduren und Funktionen aus mehreren Packages. Der empfohlene Workaround, am Ende der untersuchten Methode einen Breakpoint zu setzen, hatte allerdings in meinem Szenario nicht funktioniert.

ORA-600 [15666]

Aufgetreten unter: Oracle 12.1.0.1, Linux x64

Auf dieser Datenbank gab es schon unter 11.1.0.7 ORA-600’er im Zusammenhang mit DBMS_JOB. Da war es allerdings eine andere Ausprägung, nämlich ORA-00600 [kghquiese_1], die gelegentlich auch zum Crash der Instanz führte.

Es handelt sich um den nicht veröffentlichten Bug 19789920, der erst in 12.2 behoben sein soll. Ein One-off Patch kann aber per SR angefordert werden bzw. ist mittlerweile zum Download verfügbar.

ORA-600 [17099]

Der Fehler trat bei dem Versuch auf, eine Flashback Query für eine bestimmte Tabelle anzuzeigen.

Art des Fehlers: „Generic Error Manager Problem“ — darunter versammeln sich etliche Bugs in verschiedenen Versionen. In diesem Fall war es Bug 6451626, ein Problem im Log Miner, das als Regression in Version 10.2.0.3 erneut auftauchte und ab 10.2.0.5 bzw. 11.2 wieder behoben ist. Damit die Sache nicht zu einfach wird, hat sich mit dem Fix zu diesem Bug wiederum Bug 7361418 eingeschlichen, der auch 10.2.0.5 betrifft. Es kann also sinnvoller sein, statt auf 10.2.0.5 besser auf 10.2.0.4 Patch 40 oder gleich auf 11.2.x zu gehen.

ORA-600 [17114]

Unter 11.2.0.2.0 bei einer normal laufenden Anwendung aufgetreten, nachdem das System von 10.2.0.4 migriert wurde.

Art des Fehlers: „Memory Corruption“. In der Regel handelt es sich „nur“ um Datenfehler in einzelnen Speichersegmenten, die jedoch keinen Datenverlust in den Datafiles zur Folge haben.

Die Ursache ist noch in Klärung; Dokument 34782.1 verweist auf 12 verschiedene Bugs für Oracle 11.2, von denen 8 in der Version 11.2.0.3 behoben sein sollen.

ORA-600 [17147]

Trat unter 11.2.0.2.0 gemeinsam mit dem o.a. 17114 auf, was auf einen Bug in Oracle Text hindeutet.

ORA-600 [25027], [n]

Dieser Fehler kann in verschiedenen Szenarien im Zusammenhang mit Data Corruption auftauchen. [n] gibt hierbei den betroffenen Tablespace an. In einem Fall handelte es sich um einen Fehler im Data Dictionary unter Oracle 10.2.0.4, nach dem eine Tabelle einen Eintrag in sys.tab$ ohne einen korrespondierenden Eintrag in sys.seg$ hatte.

Oracles Health Check Script „hcheck“ brachte das Problem zutage. Die Bereinigung erfolgte anhand von Vorschlägen durch Oracle Support.

ORA-600 [bootstrapLrus_2]

Trat in einer Exadata X3 – Testumgebung bei Reboot eines Cellservers auf. Stand Oktober 2016 gibt es dazu keine Einträge auf MOS. Da die Umgebung weiterhin funktionierte, wurde kein SR eröffnet.

ORA-600 [kccscf_1], [9], [116160], [65535], [], [], [], []

Trat nach dem Klonen einer Datenbank der Version 10.2.0.3 auf. Ursache ist der nicht veröffentlichte Bug #4877360, für den in Oracle 10.2.0.3 ein Patchset existiert und der ab 11.1.0.6 als Fix eingearbeitet ist.

Workaround: Das Controlfile mit maxloghistory=65535 (bzw. dem Wert im 4. Argument des ORA-600) manuell neu erstellen.

ORA-600 [kddummy_blkchk]

Szenario: Datenbank ist mit der Einstellung „DB_BLOCK_CHECKING=FULL“ gestartet. Es lief ein SELECT FOR UPDATE (oder auch nur ein Update) über eine Index-organized Table. Der Fehler zeigt an, daß ein logisch defekter Datenblock in der Tabelle entdeckt wurde, die Details zu dem Block stehen im zugehörigen Tracefile.

ORA-600 [kocnew396]

Installation von XML DB auf einer DB, die von 10.2 auf 11.2 migriert wurde. Nach der Migration wurde die Umgebungsvariable LD_LIBRARY_PATH (Unix; unter Windows: PATH) nicht auf den 11g-Pfad umgestellt, so dass veraltete Shared Libraries ausgeführt wurden. Das kann die XDB so verkorksen, dass eine Deinstallation ebenfalls nicht mehr sauber funktioniert.

ORA-00600 [ksfd_odmcrt8], [ODM ERROR V-41-4-1-105-22 Invalid argument], …

Tritt ab Oracle 11.2.0.3 in Verbindung mit dem „Oracle Disk Manager (ODM)“ des Dateisystems VxFS auf. Siehe hierzu meinen Artikel zum ODM.

ORA-600 [pesldl01_Get_Object: shm_open: errno 2 errmsg No such file or di]

Trat in einem Batch-Prozess mit mehreren „INSERT INTO t VALUES“ auf. Von Oracle empfohlener Workaround war, die Indizes der Tabelle t (oder ggf. auch die Tabelle selbst) zu droppen und neu anzulegen.

Der Fehler wurde dadurch aber nicht beseitigt. Eine weitere Spur ist die „PL/SQL Native Compilation“ (ncomp), die Dateien nach dem Muster „.SHMDPESLD_<SID>_*“ im Verzeichnis „/tmp“ anlegt. Eine vom Sysadmin eingerichtete, regelmäßige Bereinigung des Verzeichnisses zog dann der laufenden Instanz die Kompilate unter den Füßen weg.

Mögliche Workarounds:

  • Rückschritt von Native Compilation auf Interpreted Mode. Siehe Doc ID 562586.1.
  • Einspielen der Patches für die Bugs 14571027 und 13574534. Anschließend kann über den Parameter „_ncomp_shared_objects_dir“ ein anderes Verzeichnis als „/tmp“ für die Speicherung der Kompilate gewählt werden.

Weblinks

Ein Gedanke zu „ORA-600

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s