oracle rac的心跳出现脑裂导致节点重启

故障现象：

2008年10月30日15时15分，浪潮工程师接到四一安信系统维护人员通知，核心征管数据库所在的IBM P595核心数据库自动重启。另外发现shareplex由于P595的重启损坏。（关于shareplex问题请看针对shareplex的问题处理报告）

故障排查过程：

浪潮工程师第一时间通知IBM的工程师和网络工程师到达现场。协调各方面的技术支持。

各方工程师到达现场后，浪潮工程师配合各服务支持工程师对故障进行排差。检察相关日志。

四一的工程师在4点再次尝试重启自动重启的P595，oracle crs所管理的所有服务都在线以后，节电2再次重启。

这次重启进入系统后，四一工程师停掉了oracle的群集服务crs。IBM P595和四一工程师分别再次检查服务器日志，操作系统日志，oracle警告日志，oracle群集日志等日志和跟踪文件。对交换机进行检查！

主要察看结果：

1．                P595发现3块网卡同时down掉，但恢复了2个，一个未恢复。

2．                Oracle群集维护进程日志发现，oracle的心跳出现问题，导致oracle rac为防止brain split问题。而重启问题节点。

3．                P595所连的交换机的口被disable

故障分析：

从以上三个察看结果来看，各方工程师认为。主要问题出在网络上。

1．P595发现3块网卡同时down掉，但恢复了2个，一个未恢复。说明当时网络已经不正常。

2．从oracle出现brain split问题，来看也是由于网络问题，导致心跳网络出现问题，不能同步rac各节点的instance，做实例融合等服务。导致P595重启的可能是oracle集群软件为了维护节点间的instance同步自动重启问题节点，来做问题恢复。经过排查，在2008年10月30日11点45分左右，rac节点1就以重启，目前通报的2008年10月30日15点15分左右的rac节点2所在的p595重启是此故障第2次出现。说明oracle这次未能恢复问题节点。

3．P595所连的交换机的口被disable，是因为交换机的自我保护功能在网络出现问题时，自动把问题端口置成disable。

故障处理意见：

各方工程师都对故障后现有设配，网络，平台等作了检测，均再未发现故障，所以建议重新启动oracle的集群服务，各家工程师做好监控工作，并留人进行夜间监控，做进步判断!

故障处理过程：

2008年10月31日01点0左右四一安信工程师开始oracle crs集群服务。各家工程师监控各自的系统。

故障处理结果：

   2008年10月31日01点0左右重启oracle的crs后故障未发现，目前系统正常。

幕后消息，问题交换机重启过，但是运维公司不承认!记录下吧！后续分析报告以贴出！