處理Oracle記憶體洩露 ORA-00600 [729] [space leak]

In this Document

APPLIES TO:

GOAL

The purpose of this article is to assist Oracle customers in understanding ORA-600 [729] UGA Space Leak errors. This article should help you understand what a space leak error is and what to do when one is encountered.

SOLUTION

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.

5. 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 
  Note 31056.1 - ORA-600 [729] UGA Space Leak 
for a list of known bugs and fixes.

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'

If you find them, this bug is likely:
 - Memory leak in XDB / ORA-600 [729] Note 7499301.8

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:
 - 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:
 - 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:
 - 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"

REFERENCES