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中得到了修复。接下来就是按部就班的打补丁了。