AWR报告不直接显示Interconnect故障，因其由底层OS和集群栈管理，故障不进入数据库SQL路径；需重点分析“Cluster Wait Class”及gc cr/current block busy等Global Cache等待事件异常飙升，并结合Instance Activity Stats中gc块收发量、消息丢包率等趋势变化综合判断。
awr报告本身不直接暴露interconnect互连网络故障，但能通过间接指标暴露问题——关键要看“cluster wait class”和“global cache”相关等待事件是否异常飙升。
为什么AWR里找不到“Interconnect Error”这类直白错误
Oracle RAC的Interconnect通信由底层OS（如UDP/RDS/IB）和集群栈（CSS、CRS、EVM）管理，故障通常不进入数据库SQL执行路径，因此不会生成标准等待事件或写入V$SESSION_WAIT。AWR只收集数据库层可观测的统计项，而Interconnect丢包、延迟、MTU不匹配等问题，会表现为GC（Global Cache）类等待的恶化，而非独立报错。
常见误操作是盯着Top 5 Timed Events找“interconnect”关键词——它根本不会出现。必须切换到“Cluster”等待类视图，并结合实例活动统计交叉验证。
- AWR默认不启用Cluster部分：需确保数据库为RAC模式且
STATISTICS_LEVEL≥TYPICAL（BASIC会禁用所有AWR集群指标） - 非RAC单实例库即使运行12c，
awrrpt.sql也不会输出Cluster章节 - 若报告中完全缺失“Cluster Wait Class”或“Global Cache and Enqueue Services”小节，先检查
SELECT parallel FROM v$instance是否返回YES
重点盯住这三项Cluster相关指标
打开AWR报告后，跳转至“Wait Classes by Total Wait Time”表格，重点关注以下三行：
-
Cluster等待类占比突然超过15%（正常应 -
gc cr block busy或gc current block busy平均等待时间>5ms（健康值应 -
gc buffer busy acquire次数激增，且与gc cr blocks received比值 > 0.1（说明获取block时频繁争用）
这些不是孤立数字：比如gc cr block busy升高，往往伴随gc cr blocks received下降、gc current blocks served上升——说明远程实例在服务当前块时被阻塞，根源常是Interconnect带宽打满或交换机QoS策略误限速。
用DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML提取原始GC统计
当HTML报告图表模糊或需要跨时段聚合时，绕过交互式脚本，直接查基表更可靠：
SELECT snap_id, begin_interval_time, end_interval_time,
SUM(CASE WHEN event_name = 'gc cr block busy' THEN time_waited_micro ELSE 0 END) / 1000000 AS gc_cr_busy_sec,
SUM(CASE WHEN event_name = 'gc current block busy' THEN time_waited_micro ELSE 0 END) / 1000000 AS gc_curr_busy_sec
FROM dba_hist_system_event e
JOIN dba_hist_snapshot s USING (snap_id, dbid, instance_number)
WHERE e.event_name IN ('gc cr block busy', 'gc current block busy')
AND s.begin_interval_time BETWEEN SYSDATE-1 AND SYSDATE
GROUP BY snap_id, begin_interval_time, end_interval_time
ORDER BY snap_id;
注意：time_waited_micro单位是微秒，除以1000000转为秒；若结果为空，确认dba_hist_system_event中是否存在event_name含gc的记录——没有则说明AWR未捕获到任何GC等待，此时Interconnect大概率已彻底中断（节点失联），应立刻检查crsctl check cluster和oifcfg getif。
别忽略“Instance Activity Stats”里的反常信号
翻到报告末尾的“Instance Activity Stats”章节，快速扫以下几项：
-
gc cr blocks received：每秒接收的CR块数，若从2000骤降至200，且gc current blocks received同步下跌，不是SQL变慢，是Interconnect收不到包 -
messages sent和messages received差值持续扩大（>5%），说明UDP丢包率超标 -
global enqueue gets sync突增，而global enqueue releases滞后，表明LMON进程在重试获取锁资源——典型网络抖动表现
这些数值本身不报错，但趋势比绝对值重要。例如gc cr blocks received在CPU负载不变时下降30%，比单纯看“DB CPU”高更有诊断价值——它指向基础设施层，而非SQL优化。
真正难处理的不是指标异常，而是指标“看起来正常”：Interconnect轻微丢包（0.1%）可能让gc cr block 2-way等待时间从0.3ms升至1.8ms，AWR四舍五入后仍显示“1ms”，但业务响应已慢一倍。这时候必须抓tcpdump -i bond0 port 6200或ibstat看真实链路状态。
