最常见的5个导致 RAC 实例崩溃的问题

最常见的5个导致 RAC 实例崩溃的问题 (文档 ID 1549191.1)

 


适用于:

OracleDatabase - Enterprise Edition - 版本11.2.0.1 和更高版本

本文档所含信息适用于所有平台

用途

本文档的目的是总结可能导致 RAC 实例崩溃的最常见的5种问题以及较早版本(如 10.2.0.5)报告的常见问题。

适用范围

问题 1 到 5 仅适用于 11gR2 RAC。<版本>的问题 仅适用于提及的版本。

详细信息

问题 1:ORA-29770 LMHB终止实例

症状:

LMON (ospid:31216) waits for event ‘control file sequential read‘ for 88 secs.

Errors in file /oracle/base/diag/rdbms/prod/prod3/trace/prod3_lmhb_31304.trc(incident=2329):

ORA-29770: global enqueue process LMON (OSID 31216) is hung for more than 70seconds

LMHB (ospid: 31304) is terminating the instance.

LMON (ospid: 8594) waits for event ‘control file sequential read‘ for 118 secs.

ERROR: LMON is not healthy and has no heartbeat.

ERROR: LMHB (ospid: 8614) is terminating the instance.

可能的原因:

LMON 等待读取控制文件,导致LMHB 使实例崩溃

Bug 11890804 LMHB crashes instance withORA-29770 after long "control file sequential
read" waits

解决方案:

Bug 8888434 已在 11.2.0.2 及以上版本 中得到修正

Bug 11890804 已在 11.2.0.3及以上版本中得到修正

请参阅 Document 1197674.1, Document
8888434.8
 和 Document 11890804.8 了解详细信息

问题 2:ORA-481导致的实例崩溃

症状:

1. PMON (ospid:12585): terminating the instance due to error 481

LMON 进程跟踪文件显示:

Begin DRM(107) (swin 0)

* drm quiesce <kjxgmrcfg: Reconfiguration started, type 6

LMS<x> 进程跟踪文件显示:

2011-07-05 10:53:44.218905 : Start affinity expansion for pkey 81885.0

2011-07-05 10:53:44.498923 : Expand failed: pkey 81885.0, 229 shadowstraversed, 153 replayed 1 retries

2. PMON (ospid: 4915562): terminating the instance due to error 481

Sat Oct 01 19:21:37 2011

System state dump requested by (instance=2, osid=4915562 (PMON)),summary=[abnormal instance termination].

可能的原因:

1. Bug 11875294 LMS gets stuck during DRM,Instance crashed with ORA-481

2. HAIP 在部分集群节点上离线,或者 HAIP 在所有集群节点上都在线,但是无法通过其进行通信,例如ping操作失败。

解决方案:

1. Bug 11875294 已在 11.2.0.3 中得到修正,绕过问题的方法是:

通过设置

_gc_read_mostly_locking=FALSE 来禁用read  mostly。

请参阅 < Document 11875294.8> 了解详细信息。

2. 修正 HAIP 问题,请参阅 Document 1383737.1

问题 3:ORA-600[kjbmprlst:shadow]、ORA-600[kjbrref:pkey]、ORA-600[kjbmocvt:rid]、[kjbclose_remaster:!drm]、ORA-600
[kjbrasr:pkey] 导致的实例崩溃

症状:

由于 ORA-600[kjbmprlst:shadow]、ORA-600[kjbrref:pkey]、ORA-600[kjbmocvt:rid]、[kjbclose_remaster:!drm]或 ORA-600 [kjbrasr:pkey] 导致 RAC 实例崩溃

可能的原因:

这一组 ORA-600 与 DRM(dynamic resourceremastering)消息或 read mostly 锁有关。涉及多个 bug,包括:

Document 9458781.8 Missing close message tomaster leaves closed lock dangling
crashing the instance with assorted Internalerror

Document 9835264.8 ORA-600 [kjbrasr:pkey] /ORA-600 [kjbmocvt:rid] in RAC with
dynamic remastering

Document 10200390.8 ORA-600[kjbclose_remaster:!drm]in RAC with fix for 9979039

Document 10121589.8 ORA-600[kjbmprlst:shadow] can occur in RAC

Document 11785390.8 Stack corruption /incorrect behaviour possible in RAC

Document 12408350.8 ORA-600 [kjbrasr:pkey]in RAC with read mostly locking

Document 12834027.8 ORA-600[kjbmprlst:shadow] / ORA-600 [kjbrasr:pkey] with
RAC read mostly locking

解决方案:

上述大部分 bug 都在 11.2.0.3 中得到了修正,安装 11.2.0.3 补丁集应该可以避免这些 bug,除了 Bug 12834027,此
bug 将在 12.1 中进行修正。绕过这个 bug 的方法是:

禁用 DRM

禁用read mostly

例如:设置 "_gc_read_mostly_locking"=FALSE

有关每个 bug 的说明和解决方案,请参阅上述相关文档。

问题 4:启用flash cache后产生kcldle/kclfplz/kcbbxsv_l2/kclfprm,导致实例崩溃

症状:

警报日志中报告了 ORA-7445[kcldle]

ORA-7445[kclfplz]

ORA-7445[kcbbxsv_12]

ORA-744[kclfprm]

可能的原因:

它们是由不同的 bug 引起的,而这些bug都归结为 基础bug Bug 12337941 Dumps on kcldle / kclfplz
/kcbbxsv_l2 / kclfprm using flash

解决方案:

此 bug 已在 11.2.0.3 中得到修正,请安装补丁集或使用以下方法绕过这个问题:禁用 Flash Cache

请参阅 Document 12337941.8 ,了解更多详细信息

问题 5:LMS报 ORA-600[kclpdc_21]错误,实例崩溃

症状:

警报日志中报告了ORA-600[kclpdc_21]

可能的原因:

Document 10040035.8  LMS gets ORA-600[kclpdc_21] and instance
crashes

解决方案:

此 bug 已在 11.2.0.3 中得到修正

10.2.0.5的问题

症状:

1. LMS进程 报ORA-600[kjccgmb:1]错误导致实例崩溃, LMS<n>:terminating instance due to error 484

2. 由于以下原因导致实例崩溃:

Received an instance abort message from instance 2 (reason 0x0)

Please check instance 2 alert and LMON trace files for detail.

LMD0: terminating instance due to error 481

可能的原因:

1. Bug 11893577 - LMD CRASHED WITH ORA-00600 [KJCCGMB:1]

2. Bug 9577274 - 1OFF:UNABLE TO VIEW REQUEST OUTPUT AND LOG AFTER APPLYING FIXTO ISSUE IN BUG 9400041

解决方案:

1. 对于 10.2.0.5.0,安装合并的补丁 12616787

2. 对于 10.2.0.5.5,安装合并的补丁 13470618

撰写本文时,只有特定平台才有可用补丁。对于任何 10.2.0.5.x 版本,不需要同时安装上述两个补丁。

时间: 2024-11-13 06:37:16

最常见的5个导致 RAC 实例崩溃的问题的相关文章

Oracle RAC 实例管理(Cluster Group Service)

CGS是Oracle RAC 实例管理的实现方法,负责实现如下功能 1)实例之间的心跳机制 2)当实例离开或者加入集群时完成数据库集群的重新配置 3)解决数据库层面出现的脑裂 1,网络心跳 数据库层面的网络心跳是通过LMON进程实现的,每个实例的LMON进程会定期通过数据库的私网与所有远程实例进行通信,以确认其他实例的状态,如果,某一个实例一段时间之内不能够响应其他节点发送的网络心跳信息,那么数据库集群就需要进行重新配置,用户能够看到的最直观的信息就是ora-29740错误. 2,磁盘心跳 数据

Oracle 单实例 迁移到 RAC 实例 -- 使用RMAN 异机恢复

Oracle 官网有关单实例迁移到RAC的一个步骤说明: How to Convert 10g Single-Instance database to 10g RAC using Manual Conversion procedure [ID 747457.1] http://blog.csdn.net/tianlesoftware/archive/2010/12/09/6065903.aspx   RMAN 备份异机恢复 并创建新DBID http://blog.csdn.net/tianle

srvctl和crs_start命令无法启动oracle RAC实例, 但sqlplus可以启动

今天遇到一个奇怪问题,发现srvctl和crs_start命令无法启动Oracle RAC实例,但用sqlplus却可以正常启动.最终发现原因是在OCR中数据库的状态变成了disable,将此状态更改为enable后恢复正常. 以下是一个模拟示例: [email protected]:~ $> crs_stat -t Name Type Target State Host ------------------------------------------------------------ o

对“XXX::Invoke”类型的已垃圾回收委托进行了回调。这可能会导致应用程序崩溃、损坏和数据丢失。向非托管代码传递委托时,托管应用程序必须让这些委托保持活动状态,直到确信不会再次调用它们

托管调试助手“CallbackOnCollectedDelegate”在“D:\XXX\XXX.vshost.exe”中检测到问题. 其他信息: 对“XXX+HookProc::Invoke”类型的已垃圾回收委托进行了回调.这可能会导致应用程序崩溃.损坏和数据丢失.向非托管代码传递委托时,托管应用程序必须让这些委托保持活动状态,直到确信不会再次调用它们. 经过搜索资料,发现出问题的原因是我的程序里回调函数作用域的问题 (_mouseHookCallBack) 报错前代码: private voi

对“demo!demo.Index+HookProc::Invoke”类型的已垃圾回收委托进行了回调。这可能会导致应用程序崩溃、损坏和数据丢失。向非托管代码传递委托时,托管应用程序必须让这些委托保持活

对"demo!demo.Index+HookProc::Invoke"类型的已垃圾回收委托进行了回调.这可能会导致应用程序崩溃.损坏和数据丢失.向非托管代码传递委托时,托管应用程序必须让这些委托保持活动状态,直到确信不会再次调用它们. 解救办法: //保持活动 避免 回调过程 被垃圾回收 GCHandle.Alloc(委托); 对"demo!demo.Index+HookProc::Invoke"类型的已垃圾回收委托进行了回调.这可能会导致应用程序崩溃.损坏和数据丢

对“xxx”类型的已垃圾回收委托进行了回调。这可能会导致应用程序崩溃、损坏和数据丢失。向非托管代码传递委托时,托管应用程序必须让这些委托保持活动状态,直到确信不会再次调用它们。 错误解决一例。

最近在写一个海康的门禁的自动监控刷卡事件的程序. 因为用c#写的,大家都知道c#是垃圾自动回收的.海康提供的api是用c++写的,要将处理的回调代码委托给api .刚开始的时候很顺利,但当运行一段时间就会报以下错误: 对“xxx”类型的已垃圾回收委托进行了回调.这可能会导致应用程序崩溃.损坏和数据丢失.向非托管代码传递委托时,托管应用程序必须让这些委托保持活动状态,直到确信不会再次调用它们. 大致的原因是:c#把回调函数资源回收了,导致api收到事件的时候执行回调出错. 网上的解决方案是将回调方

系统突然断电重启导致rac节点无法启动,crs-4000错误

公司rac集群为双节点oracle11g的rac,操作系统为AIX6.1,突然断电重启了,再次查看集群状态,发现其中一个节点起不来. 经过系统工程师检查,发现重启后存储的光纤网络有十几秒左右的延时,于是手动启动crs,结果保crs-4000问题.以root用户执行./crsctl start crs仍然不行. 怀疑是asm有问题,在grid用户下asmcmd,结果发现连接到空实例,真是 ASM没有启动,于是直接在asmcmd里startup没有启动.但是半天也没有反应,于是进入asm实例: sq

RAC实例 表空间 维护

先配置一下监听,这样我们就可以从客户端进行连接了. 我这里写了三种连接. 第一种是正常方式,一般都采用这种方式,后面的rac1和rac2 是方便测试.因为如果用第一种方式的话,客户端连哪个实例是随机的,不好进行控制,除非手动的关闭某个实例,让Oracle 漂过去,那样有点麻烦. 我就又多添加了2个监听,分别对应实例1和实例2.  配置这2个监听的时候,要注意Service_name 这个参数,也是orcl. 即全局名. 不是对应的实例名. Oracle 实例监听: RAC = (DESCRIPT

常见的八种导致 APP 内存泄漏的问题(上)

百度搜索:小强测试品牌 QQ群:138269539 像 Java 这样具有垃圾回收功能的语言的好处之一,就是程序员无需手动管理内存分配.这减少了段错误(segmentation fault)导致的闪退,也减少了内存泄漏导致的堆空间膨胀,让编写的代码更加安全.然而,Java 中依然有可能发生内存泄漏.所以你的安卓 APP 依然有可能浪费了大量的内存,甚至由于内存耗尽(OOM)导致闪退. 传统的内存泄漏是由忘记释放分配的内存导致的,而逻辑上的内存泄漏则是由于忘记在对象不再被使用的时候释放对其的引用导