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 |
3 参考资料
oracle官方网站案例:
Understanding and Diagnosing ORA-600 [729] Space Leak Errors [ID 403584.1]:
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=HOWTO&id=403584.1