概述

今天分享下RAC实例崩溃的4个常见bug,下面版本适用于oracle 版本11.2.0.1 和更高版本，主要是做一个备忘，方便以后直接找解决方式。

ORA-29770 LMHB终止实例

官方解释

1、报错：

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 70secondsLMHB (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.

2、思路：

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

3、解决方案：

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

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

ORA-481导致的实例崩溃

1、报错：

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.02011-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].

2、思路：

lmon进程是rac中一个非常关键的进程，主要负责集群之间的健康检查，提供gcs服务，其中当lmon出现异常时，会触发oracle级别的io fencing。

LMON主要借助两种心跳机制来完成健康检查：

1） 节点间的网络心跳（NetworkHeartbeat）：可以向节点定时的发送ping包检测节点状态，如果能在规定时间内收到回应，就认为对方状态正常

2） 通过控制文件的磁盘心跳（ControlfileHeartbeat）：每个节点的CKPT进程每隔3秒更新一次控制文件一个数据块，这个数据块叫做CheckpointProgress Record，控制文件是共享的，所以实例间可以相互检查对方是否及时更新来判断。

3、解决方案：

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

通过设置_gc_read_mostly_locking=FALSE 来禁用read mostly。

2. 修正 HAIP 问题，

11g的DRM引入了read mostly locking的机制，它会基于对象的global operation历史。

ps:

read mostly locking机制，能减少读访问的消息传递和CPU消耗，但是写访问就会比传统的cache fusion locking机制消耗更多的IO。

oracle的cache层记录着每个对象上的S lock和X lock的数量，如果某个节点打开了大量的S lock并且很少了的X lock，并且block传输的比较少，那么这个对象在这个节点上就是read mostly了。当read mostly发生的时候，对象的共享就停止了，并且block不再通过interconnect进行传输（除非block被修改）。

当一个对象被定义成read mostly，他会被master node授予在所有节点上的S affinity lock，这意味着所有的节点都被“提前”授予了该block的读访问权限，因此，减少了在各个节点间互相传递S lock的消息量。

总而言之，clsuster将会在节点数多，且X lock请求少的情况，因为read-mostly特性而收益。但是当X lock请求增加的事情，性能会急剧的降低。从另一方面说，如果你的节点数比较少，那么或许你从read mostly特性那里得不到很多好处。

而由于read mostly会消耗比较多的IO，这个时候你就要估计你一下你的IO情况了，如果你的块和消息传递的收益小于IO负载变重的情况，或者你已经处于IO压力很大的情况下，不建议开启read mostly的特性了，你可以禁用read mostly的特性。设置方式是：_gc_read_mostly_locking=FALSE

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

1、报错：

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

2、思路：

这一组 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 remasteringDocument 10200390.8 ORA-600[kjbclose_remaster:!drm]in RAC with fix for 9979039Document 10121589.8 ORA-600[kjbmprlst:shadow] can occur in RACDocument 11785390.8 Stack corruption /incorrect behaviour possible in RACDocument 12408350.8 ORA-600 [kjbrasr:pkey]in RAC with read mostly lockingDocument 12834027.8 ORA-600[kjbmprlst:shadow] / ORA-600 [kjbrasr:pkey] with RAC read mostly locking

3、解决方案：

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

禁用 DRM或禁用read mostly

例如：设置 "_gc_read_mostly_locking"=FALSE

在11g中，同样可以使用如下方式禁用DRM，强烈建议关闭：

alter system set "_gc_policy_time"=0 scope=spfile;

然后同时重启所有实例生效。如果不想完全禁用DRM，但是需要禁用read-mostly locking或者reader bypass的机制。可以使用如下命令：

--disable read-mostly locking

alter system set "_gc_read_mostly_locking"=false scope=spfile sid='*';

--disable reader-bypass

alter system set "_gc_bypass_readers"=false scope=spfile sid='*';

Oracle给出的Oracle11g下的调整：

alter system set "_gc_policy_time"=0 scope=spfile sid='*';

alter system set "_gc_undo_affinity"=false scope=spfile sid='*';

启用flash cache后产生kcldle/kclfplz/kcbbxsv_l2/kclfprm，导致实例崩溃

1、报错：

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

ORA-7445[kclfplz]

ORA-7445[kcbbxsv_12]

ORA-744[kclfprm]

2、思路：

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

3、解决方案：

此 bug 已在 11.2.0.3 中得到修正，可以选择安装补丁集或使用以下方法绕过这个问题：

禁用 Flash Cache

这个功能其实是EXADATA引入的，这也是EXADATA提高IO性能的又一利器。不过即使不是EXADATA，在11.2中也可以设置该功能，且这个功能的设置并不复杂。

11.2中提供了两个参数来设置FLASH CACHE：其中DB_FLASH_CACHE_SIZE用来设置FLASH CACHE的大小，而DB_FLASH_CACHE_FILE设置文件的位置。

在操作系统上将FLASHCACHE挂成裸设备，然后添加到单独的ASM磁盘组中或直接挂载到操作系统上，然后通过DB_FLASH_CACHE_FILE指定ASM或操作系统目录下的文件既可。

需要注意的是，DB_FLASH_CACHE_FILE不像其他参数一样，对于ASM只需要指定磁盘组的名称既可，而必须通过手工的方式在ASM磁盘组上建立对应的目录，在设置参数的过程中，目录并不会自动创建，不过指定的文件名并不需要存在，Oracle会根据DB_FLASH_CACHE_SIZE的大小自动创建文件。

SQL> alter system setdb_flash_cache_size = 30g scope = spfile;System altered.SQL> alter system setdb_flash_cache_file = '+REDO/flash/odademo1.flash' scope = spfile sid ='odaenmo1';System altered.SQL> alter system setdb_flash_cache_file = '+REDO/flash/odademo2.flash' scope = spfile sid ='odaenmo2';System altered.

需要注意，对于RAC而言，各个节点使用独立的FLASH CACHE文件，因此需要单独设置。

如果是用oracle11g的话还是比较建议大家用11.2.0.4版本，相对比较少bug，比较稳定。后面会分享更多关于DBA方面的内容，感兴趣的朋友可以关注下！！