ORA-00600: internal error code, arguments: [729] 的处理办法

该alert隔三差五的就爆出此类错误，Oracle比较头疼的难题之——internal error code。

 

ORA-00600: internal error code, arguments: [729], [600], [space leak], [], [], [], [], []

a. the first bracketed number [729] is the common argument for space leak problems.
b. the second number [600] is the number of bytes leaked by the error.
c. the third argument is always [space leak].

 

通过查找对应的trc文件，每个文件都有如下关键信息（信息安全起见，XYZ代表路径及SID，数据库名）：

Dump file /X/Z_ora_1781824.trc
Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit Production
With the Partitioning option
JServer Release 9.2.0.7.0 - Production
ORACLE_HOME = /X

System name: AIX
Node name: Z
Release: 2
Version: 5
Machine: 00C548AD4C00
Instance name: Y
Redo thread mounted by this instance: 1
Oracle process number: 16
Unix process pid: 1781824, image: oracle@Y (TNS V1-V3)

*** 2014-04-01 10:37:35.019
*** SESSION ID:(166.40177) 2014-04-01 10:37:35.014
******** ERROR: UGA memory leak detected 600 ********
******************************************************
HEAP DUMP heap name="session heap"  desc=11031e070
 extent sz=0xff80 alt=32767 het=32767 rec=0 flg=3 opc=3
 parent=1100094c0 owner=7000004fa5727d0 nex=0 xsz=0xff80

 

 

a. the memory was leaked from the UGA area
b. the amount leaked is reported again in the text (600 bytes).
c. the above few lines describe this dump as SESSION HEAP with the descriptor 0x1103a05f0

 

 

……

 

Continue to check the other information in the trc file, check the program is :

 

              DID: 0001-0039-011784AD, short-term DID: 0000-0000-00000000

              txn branch: 0

              oct: 0, prv: 0, sql: 70000051be77688, psql: 70000051be77688, user: 21/ARBOR

    O/S info: user: arbor, term: unknown, ospid: , machine: Y

              program: JDBC Thin Client

    last wait for 'SQL*Net message from dblink' blocking sess=0x0 seq=53980 wait_time=352

                driver id=28444553, #bytes=1, =0

    temporary object counter: 0

----------------------------------------

a.在logoff的时候发生UGA中的session heap发生内存泄露。
b.该进程是一个JDBC驱动导致，并且该程序已经被释放。

 

我们来看看官方某个文档对此问题的解决建议：

 

You cannot determine the cause of the space leak by checking your application code, because the error is internal to Oracle Database. You can, however, safely avoid the error by setting an event in the initialization file for your database in this form:

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

or by executing the following:

SQL>alter system set events
'10262 trace name context forever,
level xxxx' scope=spfile;
 
You will also need to shut the database down and restart it to enable the event to take effect.

Replace xxxx with a number greater than the value in the second set of brackets in the ORA-600 [729] error message. In the example above, you could set the number to 1000, in which case the event instructs the database to ignore all user space leaks that are smaller than 1000 bytes.

 

意思就说，你无法通过应用程序的代码去找出致使内存泄漏的原因。解决的办法就是加个event来屏蔽此类问题的发生。

事实上，加个event并不是解决内存泄漏的根本原因，只不过，我们可以把小于1K的内存泄漏的alert屏蔽掉。

 

 

出现ORA-00600[729]原因

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 contain only 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.

ORA-00600[729]处理方案

1. 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).
 
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.
 
2. 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.
 
3. 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.

 

参考文档：

http://www.xifenfei.com/2852.html

http://www.oracle.com/technetwork/issue-archive/2011/11-sep/o51support-453463.html

转载于:https://www.cnblogs.com/wuquan/p/3638140.html