一次RAC节点宕机的解决过程

1. 状况介绍

海哥反馈大连某院的Oracle 10g RAC平均每月都要宕机一次，一个节点自动重启，奇怪的是故障的时间没有规律，有时还发生在基本上没有业务的凌晨。医院目前使用的Windows 2003 Server(32 Bit)，数据库版本是10.2.0.3。另外海哥还反映系统还伴有Ora-04031错误。

2. 问题的诊断过程。

因为同时出现了down机和ora-04031错误，首先判断是否是因为内存耗尽，致使的一个节点down机，以前在32bit系统中遇到过相似错误;但因为down机也可能发生在系统压力很小的凌晨，这一判断首先被推翻。

向海哥索取了两个节点的alertSID.log日志和CRS日志，开始了分析。

节点１：

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

IPC Send timeout detected. Receiver ospid 5012

Tue Sep 29 06:18:31 2009 --这个时间检测到2号节点的IPC超时

Errors in file d:oracleproduct10.2.0adminora10bdumpora101_lms3_5012.trc:

Tue Sep 29 06:19:28 2009

Restarting dead background process DIAG 　--重启检测进程进行检测

DIAG started with pid=3, OS id=68680

Tue Sep 29 06:20:13 2009

Waiting for clusterware split-brain resolution　 --等待“脑裂”方案实施

 

Tue Sep 29 06:24:26 2009

IPC Send timeout detected. Receiver ospid 4768

Tue Sep 29 06:24:26 2009

Errors in file d:oracleproduct10.2.0adminora10bdumpora101_lmd0_4768.trc:

 

Tue Sep 29 06:25:29 2009

Restarting dead background process DIAG

DIAG started with pid=3, OS id=71060

Tue Sep 29 06:30:13 2009

Evicting instance 2 from cluster --1号节点将2号节点驱逐出集群,开始从新配置

Tue Sep 29 06:30:29 2009

Reconfiguration started (old inc 56, new inc 60)

………………省略部分日志……………………….

Tue Sep 29 07:26:30 2009

Submitted all GCS remote-cache requests

Post SMON to start 1st pass IR

Fix write in gcs resources

Reconfiguration complete --从新配置完成

 

 

节点2：

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

Tue Sep 29 06:18:30 2009

IPC Send timeout detected.Sender: ospid 2112 --检测到发生了IPC超时

Receiver: inst 1 binc 86089 ospid 5012

Tue Sep 29 06:18:32 2009

Errors in file d:oracleproduct10.2.0adminora10bdumpora102_lms1_2112.trc:

ORA-27508: 发送信息时发生 IPC 错误

ORA-27300: OS 系统相关操做: IPCSOCK_Send 失败, 状态为: 10055

ORA-27301: OS 故障消息: 因为系统缓冲区空间不足或队列已满，不能执行套接字上的操做。

ORA-27302: 错误发生在: send_3

 

Tue Sep 29 06:18:32 2009

IPC Send timeout to 0.4 inc 56 for msg type 65521 from opid 8

Tue Sep 29 06:18:32 2009

Communications reconfiguration: instance_number 1

Tue Sep 29 06:18:32 2009

Trace dumping is performing id=[cdmp_20090929061832]

Tue Sep 29 06:20:13 2009

Waiting for clusterware split-brain resolution --等待“脑裂”方案实施

Tue Sep 29 06:24:25 2009

IPC Send timeout detected.Sender: ospid 2116

Receiver: inst 1 binc 86087 ospid 4768

Tue Sep 29 06:24:27 2009

Errors in file d:oracleproduct10.2.0adminora10bdumpora102_lmd0_2116.trc: --这里是具体的IPC错误缘由

ORA-27508: 发送信息时发生 IPC 错误

ORA-27300: OS 系统相关操做: IPCSOCK_Send 失败, 状态为: 10055

ORA-27301: OS 故障消息: 因为系统缓冲区空间不足或队列已满，不能执行套接字上的操做。

ORA-27302: 错误发生在: send_3

 

Tue Sep 29 06:24:27 2009

IPC Send timeout to 0.0 inc 56 for msg type 65521 from opid 6

Tue Sep 29 06:30:13 2009

Errors in file d:oracleproduct10.2.0adminora10bdumpora102_lmon_4008.trc:

ORA-29740: 已被成员 1 逐出, 组原型 58 --检测到自已经被节点1驱逐

Tue Sep 29 06:30:13 2009

LMON: terminating instance due to error 29740

Tue Sep 29 06:30:13 2009

Errors in file d:oracleproduct10.2.0adminora10bdumpora102_lms0_4284.trc:

ORA-29740: 已被成员 逐出, 组原型

 

分析完了日志，基本能够肯定是因为IPC包发送失败致使CRS认为心跳失败，为了不“脑裂”现象，节点1主动驱逐了节点２;另外的几回down状况相似。在一个共享存储的集群中，当集群中hearbeat丢失时，若是各节点仍是同时对共享存储去进行操做，那么在这种状况下所引起的状况是灾难的。ORACLE RAC采用投票算法来解决这个问题，思想是这样的：每一个节点都有一票，考虑有A，B，C三个节点的集群情形，当A节点因为各类缘由不能与B，C节点通讯时，那么这集群分红了两个DOMAIN,A节点成为一个DOMAIN，拥有一票；B,C节点成为一个DOMAIN拥有两票，那么这种状况B，C节点拥有对集群的控制权，从而把A节点踢出集群，对要是通IO FENCING来实现。若是是两节点集群，则引入了仲裁磁盘，当两个节点不能通讯时，请求最早到达仲裁磁盘的节点拥用对集群的控制权。

在网络正常的状况下,IPC包发送超时，首先想到是否是遇到了bug， 到Metalink上查了查，发现一个bug与咱们的现象吻合。Bug编号为： 6782276，在10.2.0.4中获得了修复。接下来就是循序渐进的打补丁了。