凌晨数据库日志报如下错，lmon进程将数据库实例中止了：
Wed Apr 2 00:41:22 2014
Errors in file/u01/oracle/admin/epqdb/bdump/epqdb1_lmon_19974.trc:
ORA-00481: LMON processterminated with error
Wed Apr 2 00:41:22 2014
LMON: terminating instance dueto error 481
Wed Apr 2 00:41:22 2014
Errors in file/u01/oracle/admin/epqdb/bdump/epqdb1_lmd0_19976.trc:
ORA-00481: LMON processterminated with error
Wed Apr 2 00:41:22 2014
Errors in file/u01/oracle/admin/epqdb/bdump/epqdb1_lms1_19980.trc:
ORA-00481: LMON processterminated with error
Wed Apr 2 00:41:22 2014
Errors in file/u01/oracle/admin/epqdb/bdump/epqdb1_lms0_19978.trc:
ORA-00481: LMON processterminated with error
Wed Apr 2 00:41:22 2014
Errors in file/u01/oracle/admin/epqdb/bdump/epqdb1_pmon_19968.trc:
ORA-00481: LMON processterminated with error
Wed Apr 2 00:41:22 2014
System state dump is made forlocal instance System State dumped to trace file/u01/oracle/admin/epqdb/bdump/epqdb1_diag_19970.trc
Wed Apr 2 00:41:27 2014
Instanceterminated by LMON, pid = 19974
分析：
lmon进程是rac中一个非常关键的进程，主要负责集群之间的健康检查，提供gcs服务，其中当lmon出现异常时，会触发oracle级别的io fencing。
LMON主要借助两种心跳机制来完成健康检查：
1） 节点间的网络心跳（NetworkHeartbeat）：可以向节点定时的发送ping包检测节点状态，如果能在规定时间内收到回应，就认为对方状态正常
2） 通过控制文件的磁盘心跳（ControlfileHeartbeat）：每个节点的CKPT进程每隔3秒更新一次控制文件一个数据块，这个数据块叫做CheckpointProgress Record，控制文件是共享的，所以实例间可以相互检查对方是否及时更新来判断。
从lmd、lms等trace文件中均发现以下信息：
*** 2014-04-02 00:41:09.821
Received ORADEBUG command 'IPC' from process Unixprocess pid: 19974, image:
Dump of unix-generic skgm context
……
ksxpdmp: facility 2 (SKGFAIPC) (0x1,0x0000000000000000) counts 0, 0
ksxpdmp: Dumping the osd context
SKGXPCTX: 0x80000001001f4b28 ctx
WAIT HISTORY
Time(msec) WaitType Return Code
---------- --------- ------------
30 NORMAL TIMEDOUT
1 NORMAL SUCC
0 NORMAL TIMEDOUT
29 NORMAL TIMEDOUT
20 NORMAL TIMEDOUT
30 NORMAL TIMEDOUT
30 NORMAL TIMEDOUT
30 NORMAL TIMEDOUT
30 NORMAL TIMEDOUT
14 NORMAL SUCC
0 NORMAL TIMEDOUT
36 NORMAL TIMEDOUT
30 NORMAL TIMEDOUT
23 NORMAL TIMEDOUT
20 NORMAL TIMEDOUT
30 NORMAL TIMEDOUT
-- 30 是css timeout默认值
这些信息是在crash前产生的，说明当时网络出现了问题，影响到了lmon。
查看lmon的trace文件，还发现在做DRM的时候，做到31步出错：
*** 2014-04-02 00:08:09.995
Begin DRM(1053)
*** 2014-04-02 00:10:31.161
sent syncr inc 12 lvl 4553 to 0 (12,0/31/0)
sent synca inc 12 lvl 4553 (12,0/31/0)
sent syncr inc 12 lvl 4554 to 0 (12,0/34/0)
……
*** 2014-04-02 00:41:04.026
kjfcdrmrfg: SYNC TIMEOUT (864483,863582, 900), step 31
Submitting asynchronized dump request [28]
KJC Communication Dump:
state 0x5 flags 0x0 mode0x0 inst 0 inc 12
nrcv 3 nsp 3 nrcvbuf 1000
reg_msg: sz 456 cur 84 (s:0 i:84) max1526 ini 2750
big_msg: sz 8240 cur 21 (s:0 i:21) max252 ini 1934
rsv_msg: sz 8240 cur 0 (s:0 i:0) max0 tot 1000
rcvr: id 2 orapid 8 ospid 19980
rcvr: id 1 orapid 7 ospid 19978
rcvr: id 0 orapid 6 ospid 19976
send proxy: id 2 ndst 1 (1:2 )
send proxy: id 1 ndst 2 (1:1 1:3 )
send proxy: id 0 ndst 1 (1:0 )
GES resource limits:
ges resources: cur 0 max 0 ini 21522
ges enqueues: cur 0 max 0 ini 33158
ges cresources: cur 3193 max 4007
gcs resources: cur 433506 max 747472 ini952310
gcs shadows: cur 733200 max 868765 ini952310
KJCTS state: seq-check:no timeout:yes waitticks:0x3 highload no
…
error 481 detected in backgroundprocess
ORA-00481: LMON processterminated with error
可以看出在做DRM的时候到31步出错，到support.oracle.com，查找相关的信息得到如下解释：
Bug 6500033 LMON crash the instance withORA-481 due to DRM sync timeout
LMON can crash the instance with ORA-481 due to DRMsync timeout.
DIAG dumping Systemstate dump may be aborted due tolog file size limit while in server mode which can cause a DRM synctimeout when lmon unsuccessfully tries to freeze it.
结论：
根据上面的信息，可以得出0:08到0:41之间出现DRM同步超时，导致lmon异常，从而中止了数据库实例。
解决方法：
关闭DRM
可以进一步检查一下os是否有相关的错误信息，从而更加准确地定位问题根本原因。
可以通过下面两个隐含参数来禁止DRM的发生：
1. _gc_affinity_time=0
2. _gc_undo_affinity=FALSE
不过，这两个参数是静态参数，也就是说必须要重启实例才能生效。
实际上可以设置另外2个动态的隐含参数，来达到这个目的。
按下面的值设置这2个参数之后，不能完全算是禁止/关闭了DRM，而是从”事实上“关闭了DRM。
1. _gc_affinity_limit=250
2. _gc_affinity_minimum=10485760
甚至可以将以上2个参数值设置得更大。这2个参数是立即生效的，在所有的节点上设置这2个参数之后，系统不再进行DRM。
