alert日志报ORA-00600[12761]错
Sun Jun 10 13:52:56 2012 Errors in file e:\oracle\product\10.2.0\admin\interlib\udump\interlib_ora_19840.trc: ORA-04030: 在尝试分配 82444 字节 (pga heap,control file i/o buffer) 时进程内存不足 ORA-00600: 内部错误代码, 参数: [12761], [], [], [], [], [], [], [] ORA-00604: 递归 SQL 级别 2 出现错误 ORA-04030: 在尝试分配 123404 字节 (QERHJ hash-joi,kllcqas:kllsltba) 时进程内存不足
数据库版本信息
Sun Jun 10 13:52:56 2012 ORACLE V10.2.0.1.0 - Production vsnsta=0 vsnsql=14 vsnxtr=3 Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, OLAP and Data Mining options Windows NT Version V5.2 Service Pack 2 CPU : 8 - type 586, 2 Physical Cores Process Affinity : 0x00000000 Memory (Avail/Total): Ph:1263M/4095M, Ph+PgF:2716M/5976M, VA:19M/2047M Instance name: interlib
trace信息
*** 2012-06-10 13:52:56.763
ksedmp: internal or fatal error
ORA-00600: 内部错误代码, 参数: [12761], [], [], [], [], [], [], []
ORA-00604: 递归 SQL 级别 2 出现错误
ORA-04030: 在尝试分配 123404 字节 (QERHJ hash-joi,kllcqas:kllsltba) 时进程内存不足
Current SQL statement for this session:
BEGIN EM_PING.RECORD_BATCH_HEARTBEAT(:1, :2, :3); END;
----- PL/SQL Call Stack -----
object line object
handle number name
0BC35C44 1 anonymous block
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
00404686 CALLrel 00404694 0 1
0040307E CALLrel 00404660 0
0043AB6A CALLrel 00402CFC 3
603A816A CALLreg 00000000 6190E2E0 3
603A8550 CALLrel 603A80D8 6190E2E0 5E340020 31D9 0
5ED6CDF8
031B7197 CALLrel 025FA21E 6190E2E0 5E340020 31D9 2 0
02C92859 CALLrel 02C92360 5ED6D2B4 5ED6D3CC 2 61BA71E4
0 5ED6CEFA
60BAD7C6 CALL??? 00000000 5ED6D2B4 5ED6D3CC 3 61BA71E4
0 5ED6CEFA
60C41C40 CALLrel 60BAD758 5D9356A0 F1 3 5E344888
60C3C780 CALL??? 00000000 5D9356A0 951F190 5D9356DC
60C3D1BD CALLrel 60C3C748 5D9356A0 95A97F0 5D9356DC
60BB0392 CALLrel 60C3CEB0 5D9356A0
60B89393 CALLrel 60BB00B0 5D9356A0 1 0
02600CD9 CALLrel 0260F22C
0140AF2C CALLrel 02600B3C 4E8EC08
013CBFEC CALLrel 01409984 49 3 5ED6DB14
0085174B CALLreg 00000000 5E 17 5ED6F6F8
60FEFF8D CALLreg 00000000 5E 17 5ED6F6F8 0
00850A69 CALL??? 00000000
0122134B CALLrel 00850670 0 0
0085174B CALLreg 00000000 3C 4 5ED6FC90
00420E53 CALLrel 00851300 3C 4 5ED6FC90 0
00421645 CALLrel 00420B20 3C 4 5ED6FC90
0040116C CALLrel 00421618 5ED6FC84 3C 4 5ED6FC90
0040105C CALLrel 004010FC 2 5ED6FCBC
00401900 CALLrel 00401000
7C82482C CALLreg 00000000
--------------------- Binary Stack Dump ---------------------
--会话信息
(session) sid: 525 trans: 00000000, creator: 7AE024D8, flag: (41) USR/- BSY/-/-/-/-/-
DID: 0001-001B-00000004, short-term DID: 0000-0000-00000000
txn branch: 00000000
oct: 47, prv: 0, sql: 7A0F0A38, psql: 7A0A2430, user: 51/SYSMAN
O/S info: user: , term: , ospid: 1234, machine: tushuguan01
program: OMS
client info: tushuguan01_Management_Service
application name: OEM.SystemPool, hash value=2960518376
通过这里我们可以得到几个信息
1.数据库先发生了ORA-00600[12761],然后引发了ORA-04030
2.引发ORA-00600[12761]错误的原因是因为OEM的某种操作导致
3.未知因某种原因导致Call Stack Trace信息不完善,无法准确评估bug情况
4.查询数据库当前最大使用使用pga为250M,数据库配置pga为500M,原则上讲不是pga消耗完导致4030错误,可能是这个会话在执行某个基表的查询时候的hash-jion运算时pga不足导致.
5.查询dba_users发现EM_PING不是数据库用户,查询dba_source发现RECORD_BATCH_HEARTBEAT不是plsql名称,从这里可以看出OEM调用程序有一定特殊性
对于该问题的解决方案
1.因为OEM功能不太使用,建议直接关闭该进程,并设置为开机不自动启动
2.因为信息不完善,无法确定具体bug,但目前数据库版本为10.2.0.1,强烈建议升级到新版本