LMON:terminating instance due to error 481

-------------------------------------------------------------2015-07-22--------------------------------------------------------------
故障描述：
oracle rac 一个节点异常停掉，crs没有自动重启该节点

环境描述：
10.2.04 两节点rac
操作系统aix 6.1

alert日志内容如下(由于相关日志，trace文件都在内网无法取出，只好自己摘抄一些相对重要的信息)：

ora-00481:LMON process terminated with error

LMON:terminating instance due to error 481

system state dump is made for local instance

system state dumped to trace file /oracle/admin/racdc/bdump/racdc1_diag_7864580.trc

shutting down instance(abort)

license high water mark = 487

CRS中的日志：
2015-07-22 06:05:30.670:[CRSRES][11269]32In stateChanged,ora.racdc.racdc1.inst target is ONLINE

2015-07-22 06:05:30.685:[CRSRES][11269]32ora.racdc.racdc1.inst on p750sjckbak went OFFLINE unexpectedly
...
...
2015-07-22 06:05:57.551:[CRSRES][11269]32Attempting to start'ora.racdc.racdc1.inst' on member 'p750sjckbak'

2015-07-22 06:05:59.165:[CRSRES][11269]32StartResource error for ora.racdc.racdc1.inst error code=1

2015-07-22 06:06:01.063:[CRSRES][11269]32Start of 'ora.racdc.racdc1.inst' on member 'p750sjckbak' failed

简要分析：

从alert日志中可以看出，实例因为LMON进程错误，导致实例被中止。
在crs日志里面可以看到，在六点零五分时候，实例非正常offline，然后crs尝试去重启实例，但是没有成功。

在metalink上找到相关bug：
Bug 6500033  LMON crash the instance with ORA-481 due to DRM sync timeout

由于DRM超时，导致LMON进程失败，从而导致instance被意外中止。

------------------------------------------------------------------------------------------------------------------------------------------------------
在racdc1_diag_7864580.trc 这个trace文件中发现如下内容：
kjfcdrmrfg: SYNC TIMEOUT(21511687,21510786,900) step 34  --进程超时900秒
Submitting asynchronized dump request[28]
.....
.....
sync() time out - lmon exiting   ----进程超时，lmon进程退出
kjfsprn: sync status inst 0 tmout 900(sec)

简要分析：
从trace文件中可以进一步证明实例被异常中止的原因是由于drm超时导致
------------------------------------------------------------------------------------------------------------------------------------------------------
解决方法：
对于10.2.0.4版本，可以打patch来解决p6500033_10204_AIX5L.zip

另外可以禁掉drm：
--disable object affinity
alter system set "_gc_affinity_time"=0 scope=spfile ;
--disable undo affinity
alter system set "_gc_undo_affinity"=FALSE  scope=spfile;

如果暂时无法重启实例，可以使用如下命令“事实上”禁用DRM：（以下两个参数可以动态调整）

alter system set “_gc_affinity_limit”=10000000;
alter system set “_gc_affinity_minimum”=10000000;

-------------------------------------------------------------------------------------------------------------------------------------------------------
关于DRM（Dynamic Resource management）介绍：
DRM的主要功能是，根据一段时间内（默认10分钟），每个实例，对某一个数据库对象的 (10gR1以数据文件为单位)的访问次数和方式，
来决定数据库对象对应的buffer应该被mastering 到哪一个实例。
在指定时间内，如果某一个实例访问某个数据库对象次数高于其他实例一定倍数（默认50倍），则oracle 会把这个对象所有的buffer的master信息，
转移到对应实例（注意：不是转移buffer）。
当然，转移的过程是渐进式的。
当oracle 决定将一个buffer的master实例确定到本地实例后，会对这个buffer上加上affinity lock，来实现快速的访问。
这也是我们经常提到的object affinity 的由来。

DRM操作步骤：
1． Oracle停止所有在需要进行remastering的buffer上的操作。注意：DRM是渐进的，也就是说以windows 为单位，每次对一部分的buffer 进行remastering 操作。

2． Lmon 通知所有实例，准备进行remastering

3． 在旧的master实例清除对应buffer的master信息

4． 将master信息传递给新的master实例

5． 在新的master实例构建资源的最新状态

6． 结束，并释放所有之前所有步骤占用的资源。

------------------------------------------------------------------------------------------------------------------------------------------------------
关于LMON进程的介绍：
LMON主要监测群集内的全局队列和全局资源，管理实例和处理异常并相应的群集队列进行恢复操作。 

-----------------------------------------------------------------------------------------------------------------------------------------------------

最近时常出现bug方面的问题导致数据库出现异常，业务中断，越发觉得定期更新安全补丁还是非常有必要的，但生产环境往往以维稳为主，压根不会考虑停机专门去做个补丁升级等操作，谁都怕万一，万一停机后起不来了呢？谁的责任。。。。。

所以，很多时候也只能临时抱佛脚，出现了再说，万一就是不出现，岂不是很美。。。