标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (102)
- 数据库 (1,679)
- DB2 (22)
- MySQL (73)
- Oracle (1,541)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (14)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (67)
- Oracle Bug (8)
- Oracle RAC (52)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (563)
- Oracle安装升级 (92)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (79)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- 解决oracle数据文件路径有回车故障
- .wstop扩展名勒索数据库恢复
- Oracle Recovery Tools工具一键解决ORA-00376 ORA-01110故障(文件offline)
- OGG-02771 Input trail file format RELEASE 19.1 is different from previous trail file form at RELEASE 11.2.
- OGG-02246 Source redo compatibility level 19.0.0 requires trail FORMAT 12.2 or higher
- GoldenGate 19安装和打patch
- dd破坏asm磁盘头恢复
- 删除asmlib磁盘导致磁盘组故障恢复
- Kylin Linux 安装19c
- ORA-600 krse_arc_complete.4
- Oracle 19c 202410补丁(RUs+OJVM)
- ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复
- .mkp扩展名oracle数据文件加密恢复
- 清空redo,导致ORA-27048: skgfifi: file header information is invalid
- A_H_README_TO_RECOVER勒索恢复
- 通过alert日志分析客户自行对一个数据库恢复的来龙去脉和点评
- ORA-12514: TNS: 监听进程不能解析在连接描述符中给出的SERVICE_NAME
- ORA-01092 ORA-00604 ORA-01558故障处理
- ORA-65088: database open should be retried
- Oracle 19c异常恢复—ORA-01209/ORA-65088
标签归档:ORA-600 12761
因使用OEM引起ORA-00600[12761]
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,强烈建议升级到新版本