My Oracle Support Banner

ORA-00600 [729] ASSISTANT Support Document (Doc ID 1559533.1)

Last updated on NOVEMBER 16, 2016

Applies to:

Oracle Database Products
Information in this document applies to any platform.


 This document is designed to work with the Troubleshooting Assistant document SH38282

Troubleshooting Steps

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
Troubleshooting Steps
 If you received any other error immediately before the ORA-600 [729] error, please look in MOS for a resolution for that error. Resolving that error, will very likely resolve the ORA-600 [729] error as well. If the ORA-00600: internal error code, arguments: [729] persists after the other error is resolved, please continue  with this ASSISTANT to find a resolution.
 You can safely ignore this error. If you wish to stop most of these errors from appearing in your alert log, you can set the following event in init.ora parameter file. This example disables reporting for space leaks less than 90000 bytes:

        event = "10262 trace name context forever, level 90000"

We do not recommend setting the level higher than 90000. This may prevent you from seeing more serious issues. If frequent leaks greater than 90000 bytes occur please continue to use this ASSISTANT to pursue a more permanent solution.

    b. Stop and restart the database.
  If you see frequent ORA-600 [729] of greater than 90,000 bytes over an extended period, you may opt to select a different answer and pursue another solution.
Is the space leak greater than 90,000 bytes and did it occur MORE than 5 times in the last 24 hours? INVESTIGATE!!!
 Please review the trace file that was created with the ORA-600 [729] 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.
For example;

Search for "memory leak detected " in the trace file. It will show something like this.

"2006-12-13 02:01:13.859
*** 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:

For example;
  ----- 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,                 ORA-600 [729] space leak of "kxs-krole" memory
    9365381,                 ORA-600 [729] having called an external procedure followed by PMON dump
    7499301,                 Memory leak in XDB / ORA-600 [729]
    6960489,,             OERI:729 in DMON
    6870937,,,         Small memory leak / OERI[729] using SHARED_CONTEXT_SENSITIVE RLS policy
    4689285,                 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.