UGA内存泄露问题 ORA-600 [729] Space Leak Errors [ID 403584.1]

最新推荐文章于 2025-06-27 18:49:10 发布

转载最新推荐文章于 2025-06-27 18:49:10 发布 · 1.8k 阅读

Oracle管理专栏收录该内容

24 篇文章

订阅专栏

本文详细解析了Oracle UGA内存泄漏问题的原因、影响及解决方案，包括内存泄漏的定位、修复步骤以及相关补丁信息。重点介绍了如何通过调整数据库参数、重启数据库等方式来避免内存泄漏，确保数据库稳定运行。

1 根本原因分析

告警记录的时间点是01/04/2011 06:13:36 ，属于DB_Server1A 节点，查找对应数据库节点，这个时间点的alert日志，日志如下：

Fri Apr 01 06:13:36 2011

Errors in file /opt/oracle/diag/rdbms/vmsdb/vmsdb1/trace/vmsdb1_ora_12415.trc (incident=1015865):

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

Incident details in: /opt/oracle/diag/rdbms/vmsdb/vmsdb1/incident/incdir_1015865/vmsdb1_ora_12415_i1015865.trc

错误信息是ora-00600，是oracle的一个内部错误。其中[729][space leak]表示内存泄漏，[832]表示内存泄漏的字节数。

接下来需要分析本次内存泄漏的影响。

打开trace文件vmsdb1_ora_12415_i1015865.trc，日志记录：

Dump continued from file: /opt/oracle/diag/rdbms/vmsdb/vmsdb1/trace/vmsdb1_ora_12415.trc

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

========= Dump for incident 1015865 (ORA 600 [729]) ========

----- Beginning of Customized Incident Dump(s) -----

******** ERROR: UGA memory leak detected 832 ********

******************************************************

可知，本次内存泄漏存在于UGA（User Global Area）中，UGA主要存储会话信息。同时在vmsdb1_ora_12415_i1015865.trc中能搜索到“opilof”。同时alert中没有报其它错误（如：ORA-4030 或 ORA-4031错误），说明SGA没有问题。

所以，内存泄漏只涉及session退出时，UGA内存存在泄漏。

登录DB_Server1A 节点数据库，执行下面语句：

select s.SERVER,count(*) from v$session s group by s.SERVER

可知session都是以DEDICATED模式登录数据库的，DEDICATED模式下，当session退出时，泄漏异常会随着session的退出而终止，且不会造成任何业务影响，泄漏的内存也会回到UGA中。

oracle 版本从 7.0.16.0 to 11.2.0.2 一直存在这个BUG，异常本身很少重现，oracle认为小于90,000字节的内存泄漏并不会引起大问题，目前oracle只提供了规避办法，没有版本完全解决。

2 结论、解决方案及效果

2.1 结论

该问题是oracle的UGA内存泄漏BUG，在session退出时触发，在退出完成后错误终止，不会对VMS现网业务造成影响。

2.2 解决方案

这里仅提供整改思路，详细的整改步骤，根据局点不同会有所不同，由于涉及数据库的重启，会中断业务，如果一线需要实施，请一线按变更流程，提交方案评审，所有准备就绪后，才能在现网实施。

1) 检查数据库启动的文件

sqlplus /nolog

SQL> CONNECT / AS SYSDBA

Connected.

SQL> show parameter spfile;

2) 如果spfile的查询结果为空，说明是使用pfile启动的，请跳过本步骤。如果spfile的查询结果不为空（例如：/opt/oracle/product/11gR1/db/dbs/spfileVMS.ora），说明数据库是通过spfile启动的，需要把spfile转换为pfile：

sqlplus /nolog

SQL> CONNECT / AS SYSDBA

Connected.

SQL> create pfile from spfile;

File created.

pfile 创建完成，此时会在spfile相同目录下生成一个init(sid).ora文件（其中sid根据现网实际情况而定，例如：initVMS.ora）

3) 备份init(sid).ora文件。命令格式如下：

cp initVMS.ora initVMS_20110402.ora

文件名，请根据现网实际情况变更

4) 编辑init(sid).ora文件，把event = "10262 trace name context forever, level 90000"拷贝进去。拷贝进去后的文件示例：

5) 使用pfile重启数据库。

sqlplus /nolog

SQL> CONNECT / AS SYSDBA

Connected.

SQL>shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

数据库关闭成功，接下来通过指定pfile启动数据库：

SQL> startup pfile = /opt/oracle/product/11gR1/db/dbs/initVMS.ora;

ORACLE instance started.

Total System Global Area 1603411968 bytes

Fixed Size 2160112 bytes

Variable Size 1174407696 bytes

Database Buffers 419430400 bytes

Redo Buffers 7413760 bytes

Database mounted.

Database opened.

数据库启动成功。

6) 重新生产spfile；

sqlplus /nolog

SQL> CONNECT / AS SYSDBA

Connected.

SQL> create spfile from pfile;

File created.

新的spfile生成成功。

7) 验证event是否配置成功：

8) sqlplus /nolog

9) SQL> CONNECT / AS SYSDBA

10) Connected.

SQL> show parameter event;

NAME TYPE VALUE

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

event string 10262 trace name context forever, level 90000

xml_db_events string enable

如果能显示event的参数信息，说明修改成功。

11) 对于RAC、HA 数据库，各个节点都需要类似整改。

2.3 类似BUG及其解决方案

类似bug和解决补丁：

BUG	解决版本	问题描述
9474750	11.2.0.2, 12.1.0.0	ORA-600 [729] space leak of "kxs-krole" memory
7499301	11.2.0.2, 12.1.0.0	Memory leak in XDB / ORA-600 [729]
9365381	12.1.0.0	ORA-600 [729] having called an external procedure followed by PMON dump
6870937	10.2.0.4.1, 10.2.0.5, 11.1.0.7.1, 11.2.0.1	Small memory leak / OERI[729] using SHARED_CONTEXT_SENSITIVE RLS policy
6960489	10.2.0.4.1, 10.2.0.5, 11.2.0.1	OERI:729 in DMON