必须优先检查AWR报告末尾Avg global cache block receive time是否连续3个快照超100ms，该值反映真实网络层传输耗时，是GC块传输瓶颈的根因信号，非平均等待时间。
盯紧 Avg global cache block receive time 是否超 100ms
这个值不是“平均等待”，而是真实网络层传输耗时，直接暴露私网心跳延迟。AWR 报告末尾的 Avg global cache block receive time (ms) 字段必须优先检查——超过 100ms 基本可断定 GC 块传输已成瓶颈。
它和 gc buffer busy acquire 不同：gc buffer busy acquire 是争抢结果，Avg global cache block receive time 才是根因信号。OLTP 系统里哪怕只在某几个快照中反复出现 120–160ms，也要立刻下操作系统查，别等它持续恶化。
- 该指标来自
GV$SYSMETRIC_HISTORY中的Global Cache Average Block Receive Time，单位毫秒 - 注意：单次快照里偶尔抖动到 85ms 属正常；连续 3 个快照 >100ms 就需干预
- 不要用
gv$system_event的 avg_wait 计算替代——它含排队时间，不纯
查 Estd Interconnect traffic 是否突增至 MB/s 级
私网流量暴增不是负载高，而是 UDP 重传堆积的典型表现。在 AWR 报告的 Estd Interconnect traffic (KB) 项里，正常 OLTP 系统几百 KB/s 属合理；若单次快照里飙升到 24 MB/s 且与 Avg global cache block receive time 升高同步发生，大概率是 MTU 不匹配或 UDP 丢包引发。
- 执行
netstat -s | grep -i "reasm\|frag\|udp.*in"查IpReasmFails或UdpInErrors是否增长 -
ethtool eth2显示 “Link detected” 不代表质量稳，得看rx_crc_errors和tx_carrier_errors - RAC 私网建议用独立物理网卡+Jumbo Frame（MTU=9000），禁用 LRO/GRO
必须用 awrrpti.sql 生成 per-instance 报告
RAC 环境下汇总报告会掩盖节点负载不均。默认 awrrpt.sql 输出的是全局视图，真正要定位私网瓶颈，必须用 awrrpti.sql 并指定两个实例 ID，生成按实例拆分的报告。
- 命令示例：
@?/rdbms/admin/awrrpti.sql→ 选 HTML → 输入 inst_id 1 和 inst_id 2 → 指定快照范围 - 否则你会看到 “DB CPU 占 70%” 却不知道这 70% 全压在节点 1 上，而节点 1 的
cpu_count可能是节点 2 的两倍 - 真实饱和度要看
DB CPU / CPU Count比率，而非绝对值
跳过 gc cr block 2-way，盯死 gc cr block lost
gc cr block 2-way 是 RAC 正常开销，不是故障信号；真正指向底层网络问题的只有 gc cr block lost 和 gc current block lost。它们本质是 IPC send timeout，不是块丢了，是 UDP 包被丢弃或延迟超限。
- 一旦
gc cr block lost平均等待时间缓慢爬升到 16–32ms 桶，同时netstat -s里IpReasmFails持续增长，就是温水煮青蛙式恶化 - 该等待事件在 AWR 的 Top 5 中可能排第 7 或第 9，但只要
Time(s)占 DB Time >0.5%，就得手动搜gc cr block lost下钻 - 别信 “没报错就没事”——Oracle 对丢包有静默重试机制，但重试本身会放大延迟
实际排查中最容易被忽略的是：私网通信瓶颈往往不表现为节点宕机或 CRS 报错，而是以 Avg global cache block receive time 缓慢爬升 + gc cr block lost 零星增长 + Estd Interconnect traffic 波动放大为特征，三者同步出现才构成完整证据链。
