ORA-00600  ASSISTANT Support Document
(Doc ID 1559533.1)
Last updated on NOVEMBER 16, 2016
Oracle Database Products
Information in this document applies to any platform.
This document is designed to work with the Troubleshooting Assistant document SH38282
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
| ||Please review the trace file that was created with the ORA-600  error. This is indicated in the alert log beside the error message. |
In 11.x, you may need the incident trace file which has a format XXXXX_ora_xxx_ixxxxx.trc.
Please note the 'i in the last argument.
Search for "memory leak detected " in the trace file. It will show something like this.
*** SESSION ID:(54.11635) 2006-12-13 02:01:13.859
******** ERROR: UGA memory leak detected 152 ********"
In this example it indicates that the UGA memory was affected.
According to your trace file which part of memory was affected?
UGA - Determine if the leak occurred during session logoff.
<See easier option below.>
Search the trace file for "Call Stack Trace". If "opilof" is referenced in the stack, the error is happening at session logoff. The section will look similar to the following:
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp()+184 ? ksedst() 800000010000B938 ?
ksfdmp()+32 ? ksedmp() 800003FFBFFF6418 ?
kgeriv()+152 ? ksfdmp() 20000000B168 ?
kgesiv()+132 ? kgeriv() 40000000000002D9 ?
ksesic2()+124 ? kgesiv() 000000000 ?
ksmuhe()+1040 ? ksesic2() 000000000 ?
ksmugf()+400 ? ksmuhe() 000000000 ?
ksuxds()+2692 ? ksmugf() 800003FFBFFF4020 ?
ksudel()+104 ? ksuxds() 8000000100131B38 ?
opilof()+876 ? ksudel() 800003FFBFFF5808 ?
opiodr()+2416 ? opilof() 0650AB9D8 ?
ttcpip()+1320 ? opiodr() 8000000100004790 ?
opitsk()+1260 ? ttcpip() 000000100 ?
opiino()+1484 ? opitsk() 8000000100138268 ?
opiodr()+2416 ? opiino() 000001560 ?
opidrv()+752 ? opiodr() 800003FFBFFF0870 ?
sou2o()+40 ? opidrv() 000000000 ?
main()+228 ? sou2o() 000000000 ?
Alternatively, you can simply search your trace file for "opilof". This is almost as effective.
Did you find "opilof"?
If so, you can safely ignore this error. If you are using Dedicated Server, the result is just a process failure during logoff so impact is minimal. The leaked memory will be freed when the process exits (as soon as logoff is completed).
SGA -If the leak is in the SGA the alert.log should be reviewed for additional errors such as ORA-4030 and ORA-4031 to ensure there are no additional problems with the shared pool or operating system memory.
The following note may be helpful if there are ORA-4031 errors:
OERR: ORA-4031 "unable to allocate %s bytes of shared memory ("%s","%s","%s")" (Doc ID 4031.1)
Apply the latest patch set to resolve and/or rule out the following bugs and others which may have been resolved since the time of writing. The patch sets contain numerous fixes which prevent these and other issues. We urge you to maintain your database to provide the greatest protection :
Bug Fixed in Description
9474750 220.127.116.11, 18.104.22.168 ORA-600  space leak of "kxs-krole" memory
9365381 22.214.171.124, 126.96.36.199 ORA-600  having called an external procedure followed by PMON dump
7499301 188.8.131.52, 184.108.40.206 Memory leak in XDB / ORA-600 
6960489 10.2.0.4.1, 10.2.0.5, 220.127.116.11 OERI:729 in DMON
6870937 10.2.0.4.1, 10.2.0.5, 18.104.22.168.1, 22.214.171.124 Small memory leak / OERI using SHARED_CONTEXT_SENSITIVE RLS policy
4689285 10.2.0.3, 126.96.36.199 UGA memory leak and AW corrupt after maintenance
Please note that patch sets are cumulative. Therefore, the latest patch set contains all the fixes found the the earlier patch sets.
Try to determine what process is triggering the failure?
Is there a pattern in the appearance of the error, for example; Does it occur at the same time every day? If so, you can use this information to determine what might be triggering the error. Perhaps the timeline indicated that it occurs only during batch processing or when testing a new application. You can then re-run the suspect package to determine if it is indeed the cause.
Ask your sysadmin to check your operating system log for hardware issues.
My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.