最近数据库老是报ORA-00600 [729]错误，729错误是UGA内存泄露引起的，alert.log中的错误信息如下：

Fri Aug 24 10:15:25 2007
Errors in file /u01/oracle/admin/test/bdump/test_j005_2687840.trc:
ORA-00600: internal error code, arguments: [729], [1200], [space leak], [], [], [], [], []
Fri Aug 24 10:15:26 2007
Errors in file /u01/oracle/admin/test/bdump/test_j005_2687840.trc:
ORA-00600: internal error code, arguments: [729], [1200], [space leak], [], [], [], [], []

Mon Sep  3 16:29:09 2007
Errors in file /u01/oracle/admin/test/bdump/test_j000_3146712.trc:
ORA-00600: internal error code, arguments: [729], [600], [space leak], [], [], [], [], []
Mon Sep  3 16:29:10 2007
Errors in file /u01/oracle/admin/test/bdump/test_j000_3146712.trc:
ORA-00600: internal error code, arguments: [729], [600], [space leak], [], [], [], [], []

Tue Sep  4 10:25:01 2007
Errors in file /u01/oracle/admin/test/bdump/test_j002_3088582.trc:
ORA-00600: internal error code, arguments: [729], [600], [space leak], [], [], [], [], []
Tue Sep  4 10:25:01 2007
Errors in file /u01/oracle/admin/test/bdump/test_j002_3088582.trc:
ORA-00600: internal error code, arguments: [729], [600], [space leak], [], [], [], [], []

Sun Sep  9 15:34:10 2007
Errors in file /u01/oracle/admin/test/bdump/test_j000_3634104.trc:
ORA-00600: internal error code, arguments: [729], [1168], [space leak], [], [], [], [], []
Sun Sep  9 15:34:10 2007
Errors in file /u01/oracle/admin/test/bdump/test_j000_3634104.trc:
ORA-00600: internal error code, arguments: [729], [1168], [space leak], [], [], [], [], []

Sun Sep  9 20:43:50 2007
Errors in file /u01/oracle/admin/test/bdump/test_j000_2961774.trc:
ORA-00600: internal error code, arguments: [729], [2400], [space leak], [], [], [], [], []
Sun Sep  9 20:43:51 2007
Errors in file /u01/oracle/admin/test/bdump/test_j000_2961774.trc:
ORA-00600: internal error code, arguments: [729], [2400], [space leak], [], [], [], [], []

Sun Sep  9 20:49:18 2007
Errors in file /u01/oracle/admin/test/bdump/test_j001_2953286.trc:
ORA-00600: internal error code, arguments: [729], [9600], [space leak], [], [], [], [], []
Sun Sep  9 20:49:18 2007
Errors in file /u01/oracle/admin/test/bdump/test_j001_2953286.trc:
ORA-00600: internal error code, arguments: [729], [9600], [space leak], [], [], [], [], []

每次报729内存泄露的ORA-00600错误，生成了上面这些蓝色的跟踪文件，刚开始没有注意，后来发现这些蓝色的文件都有一个共同的特征，那就是都是job进程的dump文件,那么从现象来看，内存泄露与job有关了。但从trace文件看不出与哪个job有关，但看到了一条信息:wait Net message from dblink,从metalink上得到的信息看，有些过程里如果用到了database link，如果把这过程加到job里面，好像容易导致内存泄露的问题。究竟真实的原因如何，现在还很难下定论.

看看metalink上关于此错误的描述以及解决办法：

Subject:  ORA-600 [729] "UGA Space Leak"
  Doc ID:  Note:31056.1 Type:  REFERENCE
  Last Revision Date:  17-MAY-2007 Status:  PUBLISHED

Note: For additional ORA-600 related information please read Note 146580.1

PURPOSE:           
  This article discusses the internal error "ORA-600 [729]", what
  it means and possible actions. The information here is only applicable
  to the versions listed and is provided only for guidance.
 
ERROR:             
  ORA-600 [729] [a]

VERSIONS:          
  versions 7.0 to 10.1
 
DESCRIPTION:       

  A space leak has been detected in the User Global Area (UGA).

  There is NO data corruption as a result of this error.

  It is an internal memory housekeeping problem.
 
ARGUMENTS:
  Arg [a] This is the number of bytes leaked --内存泄露的大小，单位字节
 
FUNCTIONALITY:     
  MEMORY COMPONENT
 
IMPACT:            
  PROCESS FAILURE - But only during logoff so impact is minimal.
  NON CORRUPTIVE - No underlying data corruption.

 
SUGGESTIONS:       

  Event 10262 can be set to safely ignore small memory leaks.

  Set the following in init.ora for example to disable space
  leaks less than 4000 bytes:

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

  and stop and restart the database.

  Repeated errors or large memory leaks can be diagnosed further by
  sending the alert.log and trace files to Oracle support.

不过介绍的在系统参数文件中设置事件的方法是没有什么帮助的，内存泄露依然存在，只是不报出来而已。所以没有什么必要在参数文件中加此参数。因为oracle也没有其它的办法来解决此类错误，所以根源还是要我们自己来找到有问题的job,究竟具有什么样特征的存储过程容易导致此类内存泄露错误，也有可能每次泄露的原因都不尽相同，不知大家有什么诊断思路？

发生内存泄露时，常常发生的一个现象是，数据库中出现莫名其秒的大量的library cache pin等待，因为这个时候，我们根本没有进行DDL操作，所以排除由DDL操作引起，我们推测是由内存泄露引起。内存泄露有一个问题是导致有效的内存如果被覆盖，比如说一些sql语句或procedure对象的heap被部份覆盖,那么将会引起硬解析，所以出现莫名其妙的大量的library cache pin就找到了一些根据，任何事情发生都是有原因的，但在一个高度并发的，存在大量事务的数据库中，这时硬解析是非常危险的,极有可能使数据库down掉的。现在解决办法是：增大共享池大小，降低有效内存被覆盖的可能性，实践证明，这种办法是比较有效且可行的。