首先我们介绍一下历史。在Oracle 9i/10g 中，如果一个数据库实例需要驱逐(evict, alert 文件中会出现ora-29740错误）另一个实例时，需要通过LMON进程在控制文件（以下简称CF）中写入相应信息，当目标实例的LMON进程读取到相应的信息后，该实例shudown。但是，如果目标实例的LMON进程挂起而无法完成CF I/O的话，eviction将无法成功，这种情况有可能导致整个数据库挂起，需要dba手工干预。

    所以，从oracle 11gR1 开始，Member Kill Escalation的出现成功的解决了前面提到的情况。当实例eviction在指定的时间内（默认20秒）不能成功完成时，oracle会在css层面上（因为lmon进程会作为成员注册到css上，相应的内容会在今后的文章中介绍）产生一个新的进程 Kill Daemon（以下简称KD）, 终止目标实例的LMON进程以保证eviction 能够成功结束。如果情况更糟，KD进程也无法在指定的时间内（默认30秒）终止LMON进程，css 会把member kill升级为node kill，目标节点的css会重新启动本节点，以确保数据库的一致性。当然，如果您的版本是11.2.0.2或更高，由于新特性Rebootless restart的引入，node kill首先会尝试重新启动GI stack,如果不能够完成，才会重新启动节点。

    接下来我们用下面的例子说明Member Kill Escalation是如何工作的。

1.实例2发现实例1的LMS1进程出现问题，并发出member kill request.
实例2 Alert log：
Sat Jul 24 10:37:37 2010
LMS1 (ospid: 22636) has detected no messaging activity from instance 1
LMS1 (ospid: 22636) issues an IMR to resolve the situation
Please check LMS1 trace file for more detail.
Sat Jul 24 10:37:37 2010