记一次RAC数据节点2自动重启故障解决

        最近生产上出了不少“奇怪”的问题，好比下面要分享的一个故障，一套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也没有再自动重启。

        

        最后的猜测，多是因为私网网络过高致使私网网卡有拥堵，从而形成网络心跳丢失。