Understanding and
Diagnosing
ORA-600 [729] Space Leak Errors
References Support DOC: 403584.1
ORA-00600:
internal error code, arguments: [729], [560], [space leak], [], [], [], [], []
ORA-10387: parallel
query server interrupt (normal)
OPIRIP:
Uncaught error 600. Error Stack:
Effected Versions
Oracle Database - Personal Edition - Version 7.1.4.0 to 11.2.0.3
[Release 7.1.4 to 11.2]
Oracle Database - Enterprise Edition - Version 7.0.16.0 to 11.2.0.3 [Release
7.0 to 11.2]
Oracle Database - Standard Edition - Version 7.0.16.0 to 11.2.0.3 [Release 7.0
to 11.2]
Information in this document applies to any platform.
ORA-600 [729] UGA Space Leak errors.
What is a space (memory) leak?
Memory
leak problems generally occur when Oracle is trying to free memory allocated to
a process. The memory leak dump is generally discovered during session logoff,
when Oracle frees the heaps that are allocated for the user process.
When a user connects to Oracle, a user process is created and at that time the
heap is allocated. Every process will have its own memory heap.
The
memory is organized in to heaps and every heap consists of one or more extents.
Each extent contains a series of contiguous memory chunks, and these chunks can
be either FREE or ALLOCATED. The Generic Heap Manager takes care of allocating
and deallocating the memory chunks, with the help of FREE LISTS and LRU LISTS.
Chunk types are as follows:
1. FREE
2. FREEABLE
3. RECREATABLE
4. PERMANENT
5. FREEABLE WITH MARK
It is not mandatory that each extent only contains one type of chunk. Extents
can contain various types of chunks. When processes require memory chunks, they
are allocated as needed. Oracle keeps track of the amount of memory allocated
for the process internally.
When the
process terminates, all of the memory that has been allocated for the process
is automatically released. When the memory is released the allocated heaps are
freed. Generally, when the heap is freed the only chunks that the process
should identify as allocated are the PERMANENT chunks and FREE chunks on the
freelist. If the process finds there are still FREEABLE or RECREATABLE chunks
remaining, then the process has not properly deallocated the memory. This
situation is considered a space leak.
Oracle generally performs space leak checks for the SGA Heap, UGA Heap, Large
Pool Heap and PGA Heap. A space leak error will result in a trace file in the
BACKGROUND_DUMP_DESTINATION or USER_DUMP_DESTINATION.
A space
leak problem will generally capture the trace information and the heap dump.
In the
alert.log, the error will be reported as:
Errors in
file d:\oracle\admin\testdb\bdump\yourfilenamehere.trc:
ORA-00600:
internal error code, arguments: [729], [560], [space leak], [], [], [], [], []
After the
operating system and Oracle process header information you will see the
following in the trace file:
*** 2006-10-03
18:43:11.598
*** SESSION ID:(34.50354) 2006-10-03 18:43:11.597
******** ERROR: UGA memory leak detected 560 ********
The above
lines tells us that this memory leak is from the UGA and the number of bytes
leaked is 560.
******************************************************
HEAP DUMP heap name="session heap" desc=0xaef81d0
extent sz=0xffb8 alt=32767 het=32767 rec=0 flg=3 opc=3
parent=0xaeb63e0 owner=0x7a4b7078 nex=(nil) xsz=0xffb8
The above few lines describe this dump as SESSION HEAP with the descriptor
0xaef81d0.
In the dump below, you can see the chunk not released is Chunk 4085a350. This
is a recreatable chunk and the size is 560 bytes, which is exactly the number
of bytes reported as leaked in the error ORA-00600 [729], [560], [space_leak].
When analyzing memory leak issues, identify the FREEABLE and RECREATABLE
chunks. Ideally, they should equal the sum of the total amount of the memory
bytes leaked in the error reported.
If you look at the memory dump below, you see the total size of freeable and
recreatable chunks equals 560, which is the amount of the memory bytes leaked.
EXTENT 0 addr=0x407cf048
Chunk 407cf050 sz= 65456 free " "
EXTENT 1 addr=0x408a0048
Chunk 408a0050 sz= 65456 free " "
EXTENT 2 addr=0x40890048
Chunk 40890050 sz= 65456 free " "
EXTENT 3 addr=0x40850048
Chunk 40850050 sz= 41728 free " "
Chunk 4085a350 sz= 560 recreate "bind var heap " latch=(nil)
EXTENT 4 addr=0x407df048
Chunk 407df050 sz= 65456 free " "
EXTENT 5 addr=0x40f91048
Chunk 40f91050 sz= 65456 free " "
EXTENT 6 addr=0x40880048
Chunk 40880050 sz= 65456 free " "
EXTENT 7 addr=0x40870048
Chunk 40870050 sz= 65456 free " "
How do I
handle a space leak?
Step 1. Review the alert.log
to verify the error and obtain the trace file information.
The alert.log will report an error similar to the following:
Sat Dec 02 21:52:17
2006
Errors in file
d:\oracle\admin\testdb\udump\testdb_ora_5928.trc:
ORA-00600: internal
error code, arguments: [729], [152], [space leak], [], [], [], [], []
a. the first bracketed number [729] is the common argument for space leak
problems.
b. the second number [152] is the number of bytes leaked by the error.
c. the third argument is always [space leak].
Step 2.
Open the associated trace file.
Below the
operating system and Oracle process header information, you will see the
following:
*** 2006-12-13
02:01:13.859
*** SESSION ID:(54.11635) 2006-12-13 02:01:13.859
******** ERROR: UGA memory leak detected 152 ********
******************************************************
The above error states:
a. the memory was leaked from the UGA area
b. the amount leaked is reported again in the text (152 bytes).
Step 3. Verify the leak was
during session logoff.
a. 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 ?
b. The session state object has following information in flags that
shows that the session has been deleted:
SO: 7000000abdd9290, type: 4, owner: 7000000ab97a2b8, flag:
INIT/-/-/0x00
(session) sid: 617 trans: 0, creator: 7000000ab97a2b8, flag: (100041)
USR/- BSY/-/-/DEL/-/-
DID: 0000-0000-00000000, short-term DID: 0000-0000-00000000
4. Are you using Dedicated
Server or Multi Threaded Server?
a. If you
are using Dedicated Server the impact of this error will end when the process
exits. The result of this error is minimal and presents no real problem. The
leak will be in the UGA.
b. If you are using Multi Threaded Servers(MTS) and/or an XA transaction
process manager/monitor, the leaked memory is in the SGA. It is important to
review the alert.log for other errors such as ORA-4030 or ORA-4031 to ensure
the SGA is not experiencing additional resource related problems.
WORK AROUND AND SOLUTIONS
Can I ignore the leak?
a. Are there any other
errors? If there are no other errors reported at the same time, this may be a
case where the error was a rare occurrence and can be safely ignored. As a rule
of thumb, leaks less than 90,000 bytes in size are considered to be of low
significance. The solution in this case is to set event 10262 (see below).
b. Is the leak 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.
c. Does the error reproduce with a given task? If so, this is a case that
should be investigated further because the leak could be a known bug.
See
Setting EVENT 10262:
After the
amount of bytes leaked has been determined to be minimal, and no other errors
have been noted, you can choose to safely ignore the errors. Leaks up to 90,000
bytes in size are considered to be within the allowable range.
In cases
where the amount of bytes leaked is allowable and you do not want the errors to
be reported in the alert.log file, set event 10262. This will stop reporting of
the ORA-600 [729] error in the alert log file up to the specified number of
bytes.
a. 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"
b. Stop
and restart the database.
If the
level is set to 1, space leak checking is disabled. This is not advised because
large memory leaks will be missed.
If the
event is set to a value greater than 1, any space leak up to the number
specified in the event is ignored.
Are you
encountering a bug?
There are a number of bugs which can cause this issue. These are the most
prevalent at this time:
1. Search your incident trace
file for the following:
'XDB' and kgbt'
This
issue is fixed in
12.1.0.1 (Base Release)
11.2.0.2 (Server Patch Set)
2. Search your incident trace
file for the following:
kllcqgf:kllsltb
This bug is likely:
Bug 14385220 - Private memory leak of
"kllcqgf:kllsltb" memory (ORA-600 [729] / ORA-600 [723]
note
14385220.8
This is not likely to be a large leak. If the errors are small, you can mask
them by setting event 10262
as indicated above.
This issue is fixed in
12.2 (Future Release)
3. Search your incident trace
file for the following:
"kxs-role"
This bug is likely:
Bug 9474750 - ORA-600 [729] space leak of
"kxs-krole" memory Note
9474750.8
This issue is fixed in
12.1.0.1 (Base Release)
11.2.0.2 (Server Patch Set)
4. Search your incident trace
file for the following:
'hssh'
'horkmal'
'ncoxdc'
If you find any or all of these this bug is possible:
Bug 9365381 - ORA-600 [729] having called an external
procedure followed by PMON dump Note
9365381.8
This issue is fixed in
12.1.0.1 (Base Release)
11.2.0.3 (Server Patch Set)
5. For a complete list of
known fixed bugs, please see the following note:
Note
31056.1
ORA-600
[729] "UGA Space Leak"
6. Please
note that, from 11.2.0.4 onwards, ORA-600 [729] is replaced by the external
error 'ORA-10260: limit size (<nnnnn>) of the PGA heap set by event 10261
exceeded'
