最近生产上出了很多“奇怪”的问题，比如下面要分享的一个故障，一套11.2.0.4 两节点RAC数据库，2节点的集群组件会不定日期的重启，但重启的时间段比较固定，都是凌晨4:50左右。而且几分钟就会恢复。废话不多说，直接上整个问题的处理思路及过程。
2节点上的集群重启，首先会去看集群的alert日志。看到故障时间点出错如下图的报错：
日志中提示的很明显，节点之间的心跳网络丢失，导致节点2被驱逐出集群。那网络心跳丢失为什么只是集群件重启呢，这是由于从11.2.0.2开始，引入了新特性rebootless restart，对于丢失网络心跳导致的重新配置，只会发生GI重启。
那问题很明显了，集群网络心跳丢失，导致2节点的GI重启。那就来看是不是两台机器的私网网卡是不是出现了故障。
先查看osw对私网的监控日志，发现有丢包
那由以上信息能够确定是由于私网网卡故障导致的吗？
想到以前看高斌老师的书《RAC核心技术详解》有介绍过类似的现象，找来书一看，现象简直是一模一样，他那个案例中确实是由于私网网卡有故障导致的。但我们的故障也是吗？
找来网络工程师来确认网卡的情况。才知道，由于私网网卡用的是ib卡，连的是ib交换机，不属于我们自己的维护范围。于是找到数据中心来协助检查，得到的回复是没发现私网网卡有问题。
那么问题来了，私网网卡没有问题，那会是什么原因导致网络心跳丢失的呢。
又想到有zabbix监控，可以看当时私网网卡的流量情况，看是不是有流量为0的情况，如果流量为0，应该说明网卡出了问题，来看看监控图
从监控图上看出问题时间私网网络流量没有下降，反到比平时要高出很多倍，最高峰达到440.64Mbps。
从网络工程师那了解到私网网卡是千兆的，也就是流量用了网卡的50%左右。也没有达到网卡的瓶颈，那是什么原因导致网络心跳丢失，又是什么原因导致问题时段比平时高出很多呢。
正赶上一位数据分析的同事反映有一个job每天4点到5点执行，执行时间非常不稳定，有时3分钟左右执行完成有时就需要70分钟执行完。从ash看执行时间长时，主要是在等待gc的等待事件。gc是集群等待事件，说明SQL访问的相关表在其他节点有并发。从awr和他给出的sql语句中定位到主要是发生在1张大表中。
该表是从其他库通过ogg同步到本库的，该表每天凌晨0-2点都会执行跑批操作，几乎全表更新。查询同步该表的ogg进程是连接到的是2节点，而他们的应用是连接到了1节点。立马跟前面节点重启前私网流量高关联起来了，由于0-2点该表在2节点通过ogg同步更新，而到了4点多，job中的sql在1节点执行，导致私网流量过大。
似乎问题明确了，于是采取措施，把ogg及job都连接到同一个节点，防止他们出现跨节点的数据块交换。调整完后回家睡觉。
第二天早上起来，没有收到数据库4-5点dbtime高的短信告警，也没有反映节点重启，以为问题解决了。来到公司发现dbtime只是下降到了告警值下一点，比之前没有下降很多。再查看私网网络流量，也没有明显下降，只是4-5点的那个job执行时间比较稳定了，稳定在了3分钟左右。
问题还是没有解决，但数据库2节点也没有再重启，就这样放了几天。
几天后的晚上，值夜班，凌晨4：50被告警电话吵醒，数据库2节点又自动重启了。现象还是一样，重启也很快。查看私网流量还是很高，甚至达到了600Mbps。重启后登录节点2，发现上面跑了很多pxxx的进程，有100多个。由于节点2不定期重启，业务已经都连接1节点了，2节点应该不会有会话才对。从进程类型来看应该是并行会话的子进程，没有应用在跑，那并行进程又是从哪来的呢，难道是从1节点？想到前几天与同事讨论的跨节点并行，于是查看数据库的parallel_force_local配置。
果然设置的值为false，即可以跨节点执行，参数详细说明见下图：
想到这里如获至宝，于是把参数设置为false
alter system set parallel_force_local=true scope=both sid='*';
该参数设置完后，观察了几天，私网网络流量降到了以的同时段的1/10。
从监控来看私网流量已经下降了很多，观察了几天，比较稳定。节点2也没有再自动重启。
最后的猜想，可能是由于私网网络太高导致私网网卡有拥堵，从而造成网络心跳丢失。