Oracle RAC 节点驱逐故障分析方法（因ORA-29740而发生的实例终止）

节点驱逐故障分析方法（因ORA-29740而发生的实例终止）

参考文档Troubleshooting Instance Evictions (Instance terminates with ORA-29740, Instance Abort, Instance Kill) (文档 ID 1549135.1)

适用于

Oracle Database Cloud Exadata Service - Version N/A and later
Oracle Database Cloud Service - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Oracle Database Backup Service - Version N/A and later
Oracle Database - Enterprise Edition - Version 9.2.0.1 and later
Information in this document applies to any platform.

分析步骤

背景：

1、什么是节点驱逐？

Oracle Rac 集群由多个实例，如果一个或者多个实例突然中止（因被驱逐导致的实例中止）可以被称作为节点驱逐。驱逐这些实例的决定是由所有实例的共同协商一致做出的。

为什么节点被驱逐？

为了防止整个数据库集群出现问题。驱逐异常的实例避免了整个集群被HANG住。

驱逐不能与其他节点正常通信的节点避免了脑裂的产生，从而保证了集群服务的连续性。

2、怎样分辨出发生了节点驱逐？

实例会突然地异常中止。

大多数情况下，alert日志中会有以下报错：

ORA-29740: evicted by instance number <n>, group incarnation <n>
复制

少数情况下ORA-29740报错不会出现，会有以下报错：

"Received an instance abort message from instance 1"
复制

3、节点驱逐的常见原因是什么？

最常见的原因是节点间通信失败。Oracle后台进程通过private网络在节点间互相通信，如果一个其他节点不能和一个节点通信，那么该节点就会被驱逐，这就是所谓的通信重新配置，通信失败的主要原因：网络问题或者操作系统负载问题。

4、节点驱逐问题分析的关键文件

1） 每个节点的alert日志。

2） 每个节点的lmon trace文件。

5、节点驱逐诊断步骤

1）在所有节点的alert日志中查找节点被驱逐的报错信息。

2）针对ORA-29740,在lmon的trace文件中查找节点驱逐的原因。

3）查看alert日志以了解更多信息。

4）根据步骤1，2，3的结果进行检查。

Step 1 .在所有节点的alert日志中查找节点被驱逐的报错信息

• a) 在重启节点的alert日志中查找ORA-29740报错。

例如：ORA-29740: evicted by instance number 2, group incarnation 24

如果找到了ORA-29740报错信息，说明被驱逐节点的LMON进程中止了该节点。

• b) 如果没有ORA-29740报错，则在被驱逐的节点中查询以下信息：

"Received an instance abort message from instance 1"
复制

在存活的节点中有如下信息：

"Remote instance kill is issued" in the killing instance
复制

这说明实例被其他节点驱逐，但是LMON进程并没有将该节点中止并抛出ORA-29740报错。这通常是因为被驱逐节点的LMON进程繁忙或者没有正常运行。

Step 2 .针对ORA-29740,在lmon的trace文件中查找节点驱逐的原因。

• a) 查找节点重新配置的原因

检查所有节点的lmon进程trace文件，寻找带有"kjxgrrcfgchk: Initiating reconfig"的一行。文件中会给出一个原因代码例如：“kjxgrrcfgchk: Initiating reconfig, reason 3”。

注意：确保此行的时间戳在ORA-29740的时间之前不久。每次实例加入或者离开集群时都会产生此重新配置的提示。

• b) 理解重新配置的原因

Reason 0 = No reconfiguration  
Reason 1 = The Node Monitor generated the reconfiguration.  
Reason 2 = An instance death was detected.  
Reason 3 = Communications Failure  
Reason 4 = Reconfiguration after suspend

复制

对于ora-29740报错来说，目前最常见的原因为Reason 3：通信失败。

这意味着一个或多个实例的后台进程彼此之间存在通信问题。

注: RAC数据库的所有实例都需要通过互连彼此保持持续通信，以保持数据库的完整性。

在11.2版本的数据库中，alert日志还会输出原因为Reason 3的报错提示信息：

Communications reconfiguration: instance\_number <n>
复制

如果您看到此提示（Reason 3或通信重新配置），请执行step 4（a）-网络检查中的检查。

如果您发现了不同的重新配置原因，请仔细检查以确保您看到的是正确的重新配置，即ora-29740发生在最后一条“kjxgrrcfgchk”消息以后。有关其他重新配置原因的更多信息，请参阅 Document 219361.1。

Step 3 . 查看alert日志以了解更多信息。

在节点驱逐前不久，在任意实例的alert日志中查找以下任何消息：

1. "IPC Send Timeout"

例如 节点1的alert日志中有如下信息:

IPC Send timeout detected.Sender: ospid 1519  
Receiver: inst 8 binc 997466802 ospid 23309
复制

这意味着具有实例1的ospid 1519的进程试图向实例8的ospid 23309进程发送消息。实例1 ospid 1519在等待实例8 ospid 23309的确认时超时。

要找出每个ospid对应的后台进程，请在相应的alert日志中查找之前的实例启动信息。所有后台进程的ospid都在实例启动时列出。

例如：

Thu Apr 25 16:35:41 2013  
LMON started with pid=11, OS id=15510  
Thu Apr 25 16:35:41 2013  
LMD0 started with pid=12, OS id=15512  
Thu Apr 25 16:35:41 2013  
LMS0 started with pid=13, OS id=15514 at elevated priority
复制

一般来说，在alert日志中出现IPC send timeout报错有两种原因：

(1)  节点互相通信时网络愿意导致的IPC信息无法传递。

(2) 互相通信的发送或者接收进程没有正常工作。这可能是由操作系统负载或调度问题，或数据库/进程挂起或在数据库等待级别阻塞引起的。

如果看到此提示， 请进行step 4的所有检查.

2. “Waiting for clusterware split-brain resolution” or "Detected an inconsistent instance membership"

这个信息通常是在通信重新配置时出现。

例1：

Mon Dec 07 19:43:07 2011
Communications reconfiguration: instance_number 2
Mon Dec 07 19:43:07 2011
Trace dumping is performing id=[cdmp_20091207194307]
Waiting for clusterware split-brain resolution

例2：

Thu Mar 07 17:08:03 2013
Detected an inconsistent instance membership by instance 2

这两条信息都表明脑裂的发生。这表明通过实例之间的通信存在持续且严重的问题。

如果看到此提示, 请进行 step 4(a) 中的网络检查.

3. " detected no messaging activity from instance "

例如：

LMS0 (ospid: 2431) has detected no messaging activity from instance 1
LMS0 (ospid: 2431) issues an IMR to resolve the situation

这意味着后台进程（上例中的LMS0）在一段持续的时间内没有从另一个实例接收到任何消息。这强烈表明互连上存在网络问题，或者另一个实例挂起。

如果看到此提示,  请首先进行 step 4(a) , 如果没有发现问题,进行4(b) 和4©的检查.

4. None of the above

如果在alert日志中没有看到上述任何消息，但在日志中看到了ora-29740，则执行所有检查，从4（a）-网络检查开始。

Step 4 .根据步骤1，2，3的结果进行检查。

4(a)- 网络检查

*检查网络，确保没有网络错误，如UDP错误、IP数据包丢失或故障错误。

*检查网络配置，确保所有节点的网络配置都正确。

例如，所有节点上的MTU大小必须相同，如果使用巨型帧，交换机可以支持9000的MTU大小。

*如果正在使用OSW，请检查已存档的“oswprvtnet”，查看private网络的任何中断信息。有关更多信息，请参阅 Document 301137.1。

4(b)- 在操作系统级别检查操作系统挂起或严重的资源争用。

*检查OSW或CHM中已存档的vmstat和top结果，查看服务器是否存在CPU或内存负载问题、网络问题或lmd或lms进程问题。

4© - 检查数据库及进程是否有挂起。

*检查alert日志，查看在ora-29740之前是否进行了任何hanganalyze dump，因为实例或进程挂起会触发自动hanganalyze dump。如果存在hanganalyze dump请参阅Document 390374.1。

*检查alert日志，查看是否在ora-29740之前进行了systemstate dump。如果产生了systemstate dump，Oracle支持部门可以帮助分析systemstate dump。

*检查OSW或CHM中存档的OS统计信息，查看是否有LM*后台进程信息。

Known Issues

Document 1440892.1 - 11gR2: LMON received an instance eviction notification from instance n