联系:手机/微信(+86 17813235971) QQ(107644445)
作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
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,强烈建议升级到新版本
ORA-00600 [12761] CAUSING THE SESSION TO CRASH.