1 、故障描述
某次，接到用户反馈数据库无法连接，业务无法正常提供服务。由于影响面较大，立即着手排查。检查数据库集群和DB 服务状态正常，监听状态正常，尝试带连接串 SQLPLUS 可访问数据库，检查 cpu ， io, 实例日志，系统日志， GI 日志无明显报错。检查等待事件存在大量 gc cr 相关等待，该等待一般是两个节点间数据交互产生，联系网络工程师协助排查网络状况，清理节点二所有会话，关闭节点二实例后对外服务恢复正常，现暂时由节点一对外提供服务。我们根据现有的日志，结合该环境本身的一些技术指标，给出一个可预判的故障报告。
2 、根因分析
1) 检查主机负载
主机整体负载，与平时差异不大。
2) 检查数据库告警日志
数据库实例告警日志无明显报错。
3) 检查操作系统日志
操作系统日志未出现明显报错。
4) 等待事件分析
数据库主要等待事件为 gc cr 相关等待， cr 块的传输主要有 2 个操作，一个是当前块的 redo 落盘和跨节点传输。故障期间检查 2 个节点的 redo 没有异常。 GC 等待长时间无法截取 AWR 报告。清理节点二所有会话，关闭节点二实例对外服务恢复正常，现暂时由节点一对外提供服务。
5) 集群gc 核心指标排查
异常时间段：
正常时间段：
通过 awr 检查跨节点传输，发现跨节点传输接收时间异常，发送消息排队时间异常， % of flow controlled messages 流控管理超过了 51% ，正常时间段 0.12% 。
说明当时操作系统出现了瓶颈， CPU 过高，或网络延迟大或网络负载过高等情况。但实际出现问题时 CPU 负载并不高。
6) OSWatch 指标监控
通过查看 osw 监控和系统内核日志显示当时网络组包失败严重（ IP reassembles failed ），网卡检测到链路不稳定自动降低链路速度到百兆，需要排查网络问题。
3 、解决方案
经过网络工程师检查交换机日志发现该 RAC 集群在故障时间点，心跳线网络由千兆带宽降至百兆带宽，基于以上结果判定，此次数据库 hang 住问题是由心跳网络降级导致。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/30310891/viewspace-3028110/ ，如需转载，请注明出处，否则将追究法律责任。
