Dump In kokacau() And PMON Crashes With ORA-600 
(Doc ID 360194.1)
Last updated on FEBRUARY 03, 2019
Applies to:Oracle Database - Enterprise Edition - Version 188.8.131.52 to 10.2.0.1 [Release 9.2 to 10.2]
Information in this document applies to any platform.
***Checked for relevance on 28-Feb-2012***
Core dump in kokacau() followed by PMON crashing the instance with ORA-600 
Stack from the kokacau() dump is similar to:
... kokacau rpiswu2 kokavpr koklcprv koklglfn koklglen koklc_length kole_length kokle_length evaopn2 qersoRowP qertbFetch qersoFetch ...
and the current SQL statement is a query on tabpart$ similar to:
select obj#, dataobj#, part#, hiboundlen, hiboundval, ts#, file#, block#, pctfree$, pctused$, initrans, maxtrans, flags, analyzetime, samplesize, rowcnt, blkcnt, empcnt, avgspc, chncnt, avgrln, length(bhiboundval), bhiboundval from tabpart$ where bo# = :1 order by part#
Stack from the PMON trace is similar to:
... kglunp kkscls opicca opiclo opifcs ksurus ksuxdl ...
The SYS.AUD$ table was recreated as a partitioned table in order to make maintenance of audit records easier. During that operation, the table may have been relocated to a non-SYSTEM tablespace as well, but this is not a required step to be exposed to the problem.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document
|This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review.|