ORA-00600: internal error code, arguments: [510]
Verfasst von Tenebrias am 21.04.2008 - 13:58
Der Montag fängt gut an. Nachdem es einige Probleme mit der Produktivierung unserer ersten 11g-Datenbank gab, haben wir auf einer anderen 10.2.0.3 Datenbank seit heute massiv auftretende ORA-00600.
Im alert.log sieht das wie folgt aus:
Mon Apr 21 11:44:55 2008 Errors in file /opt/erlf0vl0v1/home/oracob/oracle_base/diag/rdbms/COBP/COBP/bdump/cobp_mmon_12039.trc: ORA-00600: internal error code, arguments: [510], [0x3800245E8], [threshold alerts latch], [], [], [], [], []
Bevor nun jemandem die Augen rausfallen: Ja, das ist eine 10gR2, die eine 11g-Struktur faked. Aber zur Sache.
Im Call-Stack-Trace wird es hübsch:
*** SERVICE NAME:(SYS$BACKGROUND) 2008-04-21 11:44:55.097 *** SESSION ID:(491.11629) 2008-04-21 11:44:55.097 *** 2008-04-21 11:44:55.097 ksedmp: internal or fatal error ORA-00600: internal error code, arguments: [510], [0x3800245E8], [threshold alerts latch], [], [], [], [], [] ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- ksedmp()+744 CALL ksedst() 000000840 ? FFFFFFFF7FFFC44C ? 000000000 ? FFFFFFFF7FFF8F40 ? FFFFFFFF7FFF7CA8 ? FFFFFFFF7FFF86A8 ? kgeriv()+220 PTR_CALL 0000000000000000 000106400 ? 106532264 ? 106532000 ? 000106532 ? 000106400 ? 106532264 ? kgesiv()+112 CALL kgeriv() 10652CC18 ? 000000000 ? 0000001FE ? 000000002 ? FFFFFFFF7FFFC9A8 ? 000001430 ? ksesic2()+96 CALL kgesiv() 10652CC18 ? FFFFFFFF79820040 ? 0000001FE ? 000000002 ? FFFFFFFF7FFFC9A8 ? 000001420 ? kslfre()+1040 CALL ksesic2() 0000001FE ? 00010652C ? 106532258 ? 000106400 ? 106532000 ? 000106532 ? ktte_check_threshol CALL kslfre() 3800245E8 ? 000106400 ? d()+1404 000000000 ? 00000000A ? 000106400 ? 10574DE84 ? ktte_check_undo_tbs CALL ktte_check_threshol 000000001 ? 000280000 ? ()+300 d() 000280000 ? 0001FC048 ? 000000000 ? 000000000 ? ktte_monitor_tsth() CALL ktte_check_undo_tbs 00000077B ? 380017DC4 ? +1744 () 000000CC0 ? 000000001 ? 000000000 ? 0001FC048 ?
Eine kurze Suche auf Metalink führt zu DocId 395380.1: ORA-00600: [510], [], [threshold alerts latch] is being reported by MMON process und der Aussage: Problem was likely introduced after adding alerts for threshold values on tablespaces.
Öh. Ja, das kommt mir bekannt vor. Da hatte ich doch heute erst ein paar Schwellwerte für den UNDO-Tablespace eingeführt. Die schöne Aussage der Note ist: Gefixt in 11g, Workaround: Abschalten der Metric.
O_O.
Und das ist wahrscheinlich auch noch ernst gemeint.
Ein wenig weitergehende Suche zeigt mir:
- Die Eintragung der Werte für den Tablespace erscheint nicht in der passenden Metrik Tablespace Free Space (MB)
- Der händische Eintrag an dieser Stelle bleibt ohne Wirkung
- Ein äquivalenter Metrikeintrag für einen anderen Tablespace direkt bei Edit Tablespace im Grid bringt keine Fehler.
Und nun wird es interessant. Ich packe wie vorher auch schon mehrfach wieder Tresholds für den crashverursachenden Tablespace rein, ändere aber die Werte und es funktioniert tadellos. Mhm. Doof geguckt, dann probeweise auf den originalen Treshold gestellt, der vorher nach jedem Aktivieren/Deaktivieren Probleme machte – und es geht. Toll.
