大清早的，核心数据库又夯死了！

上周某个早晨，客户电话说数据库有性能问题，这里简单分析共享一下。 

由于当时远程很多操作没有记录。这里用事后采集的awr和tfa收集的数据给大家做下分享。

如下是节点2早上8点-8:40的awr top event。

从等待来看，很明显gc有问题，甚至出现了gc cr failure。

进一步从rac 部分数据来看，心跳数据交互每秒接近50MB，gc cr block flush，current block flush 等很慢很慢，但是log flushs似乎还很ok。

实际上当时故障期间，我甚至都没有来得及细看awr，都是直接查询gv$session判断，当时通过一些event判断集群通信可能存在异常，怀疑是不是心跳丢包了，然后通过ifconfig 观察了一下心跳，发现确实有点问题。

实际上也就是从8:08左右，数据库开始出现明显异常，最后甚至节点1在8:21出现了重启。

由于当时是早高峰，因此为了尽快恢复业务，跟客户沟通之后，我建议先停止节点1，先单节点2跑业务。

果然不出所料，节点1数据库实例shutdown之后，业务即可恢复了正常。

作为事后复盘这个case，那么我们来找找原因，期间大家从集群心跳丢包到存储，网卡驱动兼容性等等都做过猜测。

对于osw看到的数据，ifconfig中心跳望领导RX 有missed的情况，分析了一下大致是这个可能性原因：

我们检查了做bond的2个心跳网卡，发现rx和tx队列buffer确实都是默认值。

也就是说可能当集群堵塞严重，恰好早高峰的时候，连接不断增多，导致心跳流程加大，出现了RX missed的情况。

对于心跳流程，后面我对比前一天早高峰的数据，发现相比这次故障期间的心跳流量，发现差了很多【如下是前一天早高峰的rac报告】。

后面可以检测存储和网络，发现存储有相关报错，实际上早上7:40左右就开始出现了。

后面我登录环境看history event发现时间也是符合的，大量的gcs log flush sync等待。

后面检测发现是有个存储链路端口有异常，时好时坏。

最后禁掉该异常端口之后，直接启动节点1，发现整个集群就恢复正常了。

现在回过头来看最前面的awr rac部分内容，其实可以看到gc cr block/current block flush time是极高的，说明数据落盘是存在异常的。

这个case最后我们简单总结一下：

1、不能单纯的只看gcs log flush 很慢或者有丢包就认为一定是心跳有问题； 

2、存储链路异常即dbwr 写数据落盘异常，也会阻塞lgwr。