ORA-00600[kghstack_underflow_internal_3]

在11.2.0.3.6双节点RAC环境中,凌晨时段出现ORA-600错误,错误日志显示为[kghstack_underflow_internal_3]。问题可能由并发的在线DDL操作导致,重建索引时影响DML会话,触发该内部错误。解决方案涉及检查和处理数据库的堆栈溢出问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

环境:11.2.0.3.6 双节点RAC
系统:aix power system 6.1
问题:一个节点在凌晨出现ORA-600错误
alert日志:
Global Enqueue Services Deadlock detected. More info in file
 /u01/app/oracle/diag/rdbms/trsen/trsen2/trace/trsen2_lmd0_20513176.trc.
Wed Jul 16 23:59:59 2014
Errors in file /u01/app/oracle/diag/rdbms/trsen/trsen2/trace/trsen2_ora_10420630.trc  (incident=6917166):
ORA-00600: 内部错误代码, 参数: [kghstack_underflow_internal_3], [0x1109BAFC8], [keybuf], [], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/trsen/trsen2/incident/incdir_6917166/trsen2_ora_10420630_i6917166.trc
Thu Jul 17 00:00:04 2014
Errors in file /u01/app/oracle/diag/rdbms/trsen/trsen2/trace/trsen2_ora_21430462.trc  (incident=6918870):
ORA-00600: 内部错误代码, 参数: [kghstack_underflow_internal_3], [0x1109DAFC8], [keybuf], [], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/trsen/trsen2/incident/incdir_6918870/trsen2_ora_21430462_i6918870.trc
Thu Jul 17 00:00:06 2014
Errors in file /u01/app/oracle/diag/rdbms/trsen/trsen2/trace/trsen2_ora_3802044.trc  (incident=6919270):
ORA-00600: 内部错误代码, 参数: [kghstack_underflow_internal_3], [0x11091AFC8], [keybuf], [], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/trsen/trsen2/incident/incdir_6919270/trsen2_ora_3802044_i6919270.trc
Thu Jul 17 00:00:06 2014
Errors in file /u01/app/oracle/diag/rdbms/trsen/trsen2/trace/trsen2_ora_22872348.trc  (incident=6916846):
ORA-00600: 内部错误代码, 参数: [kghstack_underflow_internal_3], [0x1108AAFA8], [keybuf], [], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/trsen/trsen2/incident/incdir_6916846/trsen2_ora_22872348_i6916846.trc
Thu Jul 17 00:00:06 2014
Dumping diagnostic data in directory=[cdmp_20140717000006], requested by (instance=2, osid=21430462), summary=[incident=6918870].
Thu Jul 17 00:00:06 2014
Errors in file /u01/app/oracle/diag/rdbms/trsen/trsen2/trace/trsen2_ora_20710582.trc  (incident=6919326):
ORA-00600: 内部错误代码, 参数: [kghstack_underflow_internal_3], [0x11099AFA8], [keybuf], [], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/trsen/trsen2/incident/incdir_6919326/trsen2_ora_20710582_i6919326.trc
Thu Jul 17 00:00:07 2014
Errors in file /u01/app/oracle/diag/rdbms/trsen/trsen2/trace/trsen2_ora_4588318.trc  (incident=6918646):
ORA-00600: 内部错误代码, 参数: [kghstack_underflow_internal_3], [0x11098AFA8], [keybuf], [], [], [], [], [], [], [], [], []
Thu Jul 17 00:00:07 2014
Errors in file /u01/app/oracle/diag/rdbms/trsen/trsen2/trace/trsen2_ora_12650346.trc  (incident=6924446):
ORA-00600: 内部错误代码, 参数: [kghstack_underflow_internal_3], [0x1108B74D0], [keybuf], [], [], [], [], [], [], [], [], []
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.

从alert日志里可以看到由于调用这个函数[kghstack_underflow_internal_3],报错,接下来,看一下提示的详细trc文件

trc文件内容:
Dump continued from file: /u01/app/oracle/diag/rdbms/trsen/trsen2/trace/trsen2_ora_10420630.trc
ORA-00600: 内部错误代码, 参数: [kghstack_underflow_internal_3], [0x1109BAFC8], [keybuf], [], [], [], [], [], [], [], [], []
========= Dump for incident 6917166 (ORA 600 [kghstack_underflow_internal_3]) ========
*** 2014-07-16 23:59:59.721
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
----- Current SQL Statement for this session (sql_id=11va1wb1z3hdm) -----

----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
skdstdst()+40        bl       107c70e00            000000000 ? 000000001 ?
                                                   000000003 ? 000000000 ?
                                                   000000000 ? 000000001 ?
                                                   000000003 ? 000000000 ?
ksedst1()+112        call     skdstdst()           13816ED051D6EE31 ?
                                                   484428412F737464 ?
                                                   FFFFFFFFFFEF900 ? 000002004 ?
                                                   11050CC00 ? 10A252BD4 ?
                                                   000000000 ? 11050CC00 ?
ksedst()+40          call     ksedst1()            30300000000 ? 002050033 ?
                                                   10A252BC8 ? 700000000025C ?
                                                   000000000 ? 000000000 ?
                                                   10A252228 ? 000000000 ?
dbkedDefDump()+1516  call     ksedst()             000000000 ? 000000000 ?
                                                   FFFFFFFFFFEFAF0 ? 000000000 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ? 300000003 ?
ksedmp()+72          call     dbkedDefDump()       300000000 ? 1100009F8 ?
                                                   FFFFFFFFFFF00E0 ?
                                                   4844424409A07784 ?
                                                   10011CA24 ? 109A07778 ?
                                                   FFFFFFFFFFF0130 ? 110454B90 ?
ksfdmp()+100         call     ksedmp()             000000000 ? 000000000 ?
                                                   009A07793 ? 10AC18EC0 ?
                                                   200000000000000 ? 000000000 ?
                                                   1106DC4E8 ? 11050CC00 ?
dbgexPhaseII()+1940  call     ksfdmp()             000002004 ? 11050CC00 ?
           
<think>好的,我需要帮助用户解决ORA-06512错误,特别是与DBMS_SNAPSHOT包相关的情况。首先,我要理解这个错误的背景。根据引用[1],错误信息提到了ORA-04062,指出DBMS_SNAPSHOT_UTL包的时间戳被更改,导致ORA-06512错误。ORA-06512通常表示错误发生的位置,是Oracle数据库中的一个常见错误,通常伴随其他错误代码出现。 接下来,我需要分析可能的原因。根据引用[1]中的例子,当执行dbms_snapshot.refresh时,包的状态被丢弃,可能是因为包被重新编译或修改过。这会导致会话中的包版本不一致,从而引发错误。另外,ORA-04068也提到包的状态被丢弃,这可能与依赖对象的变化有关。 解决方案方面,首先应该确保所有相关包处于有效状态。用户可能需要重新编译无效的对象,如执行utlrp.sql脚本。此外,检查是否有其他会话或作业在修改包,避免在刷新物化视图时进行结构变更。如果问题持续,可能需要完全刷新物化视图而不是使用增量刷新,或者联系Oracle支持处理潜在的内部错误。 另外,引用[4]提到ORA-00600内部错误,虽然这里不是直接相关,但提醒我需要考虑事务状态的问题。不过当前问题主要与包的状态变化有关,所以重点应放在包和依赖管理上。 最后,我需要将解决方案分步骤列出,确保用户能清晰理解和操作。同时,生成相关问题,帮助用户扩展知识,比如如何诊断包无效、ORA-04062的解决方法等。</think>### ORA-06512错误与DBMS_SNAPSHOT的解决方案 #### 错误原因分析 1. **包状态失效** 当调用`DBMS_SNAPSHOT`包时,若其依赖对象(如`DBMS_SNAPSHOT_UTL`)的时间戳或定义发生变更(例如重新编译、升级或补丁操作),会导致会话中缓存的包版本与实际存储的版本不一致,触发ORA-04062错误并伴随ORA-06512定位信息[^1]。 2. **事务状态冲突** 若数据库尝试提交未正确结束的事务(如引用[4]中的内部事务指针异常),可能间接影响包执行,但此类情况较少见。 --- #### 解决步骤 1. **重新编译无效对象** 运行以下脚本修复无效的包和依赖对象: ```sql ALTER PACKAGE SYS.DBMS_SNAPSHOT_UTL COMPILE; ALTER PACKAGE SYS.DBMS_SNAPSHOT COMPILE; -- 重新编译所有无效对象 @?/rdbms/admin/utlrp.sql ``` 2. **确保事务一致性** 在调用`DBMS_SNAPSHOT.REFRESH`前提交或回滚所有未完成的事务: ```sql COMMIT; BEGIN DBMS_SNAPSHOT.REFRESH(&#39;AS_GROUP&#39;, &#39;C&#39;); END; ``` 3. **调整刷新模式** 若使用`COMPLETE`模式可避免增量刷新时的依赖问题: ```sql BEGIN DBMS_SNAPSHOT.REFRESH(&#39;AS_GROUP&#39;, &#39;C&#39;, atomic_refresh => FALSE); END; ``` 4. **排查外部依赖** 检查物化视图的基表是否正常(如引用[2]中的外部表文件缺失问题),确保数据源可访问且无权限异常。 5. **监控会话冲突** 使用以下查询检查是否有并发操作影响包状态: ```sql SELECT sid, serial#, sql_id, status FROM v$session WHERE module LIKE &#39;%DBMS_SNAPSHOT%&#39;; ``` --- #### 关键操作示例 ```sql -- 示例:强制刷新并忽略无效状态 BEGIN DBMS_SNAPSHOT.SET_IMMEDIATE(&#39;AS_GROUP&#39;); DBMS_SNAPSHOT.REFRESH(&#39;AS_GROUP&#39;, method => &#39;C&#39;); END; ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值