看到gc cr block lost或gc current block lost进入Top 5即表明私网通信已出问题，本质是IPC send timeout或UDP重传失败，而非块真丢失；平均等待>1000ms、netstat显示重传飙升、AWR中互连流量突增至数MB/s均需立即排查OS层网络。
怎么看gc cr block lost才算真出问题
看到 gc cr block lost 或 gc current block lost 进了 Top 5，别急着调 SQL 或加索引——这基本等于私网通信已超时。它不是块真丢了，是 IPC send timeout 或 UDP 重传失败导致请求没回音。
- 平均等待时间 >1000 ms（即 >1 秒）必须立刻查 OS 层：用
ping -s 1472测集群私网 MTU 是否匹配，netstat -s | grep -i "retransmit"看 UDP 重传是否飙升 - 如果 AWR 里
Estd Interconnect traffic (KB)从几百 KB/s 突增至几 MB/s（比如 24 MB/s），说明 Cache Fusion 流量暴增，大概率是丢包引发重传堆积 -
gc cr block 2-way和gc current block 2-way是正常开销，占比高不等于故障；但若它们的 Avg Wait 同步超过 5ms，就得怀疑底层延迟已传导上来
生成真正有用的RAC全局AWR报告
用 @?/rdbms/admin/_awrgrpt.sql 默认只查当前实例，GC 统计全漏掉。必须用 @?/rdbms/admin/awrgrpt.sql 并显式填 inst_num = 0 才能拉出含 Global Cache Statistics 的全局报告。
- 连任一节点后执行
@?/rdbms/admin/awrgrpt.sql，提示 “Instance Number” 时输0 - 生成后翻到报告末尾，确认出现
Global Cache Efficiency小节；没有就说明没走集群模式 - 若坚持用
_awrgrpt.sql，得在脚本开头手动加DEFINE inst_num = 0;，否则它默认把inst_num设为当前实例号
交叉看三组数据才能定位GC争用源头
单看 Top 5 等待事件占比会误判。必须同时盯死：Avg global cache block receive time (ms)、Global Cache Load Profile 中的 Blocks served / Blocks received 比值、以及 gc buffer busy acquire 的 Avg Wait + Waits 频次。
-
Avg global cache block receive time>10 ms → 私网延迟严重，不是数据库配置问题 - 某节点
Blocks received远大于Blocks served→ 它正在被动“拉块”，大概率已是瓶颈节点 -
gc buffer busy acquireAvg Wait >5 ms 且 Waits 次数突增 → 不是锁本身慢，是 CR 块卡在传输途中，后续进程争抢同一 buffer 堆出来的连锁反应
用p1/p2反查争用对象时最容易踩的坑
p1 和 p2 在不同 GC 等待事件中含义完全不同，直接套用会查错对象。比如 gc current block busy 的 p1 是 file#，但 gc buffer busy acquire 的 p1 是 class#，必须先查 v$event_name 确认语义。
- 查分区表时漏掉
partition_name，容易定位到父段而非实际热点分区 - 若反查出块属于 UNDO 段，说明是回滚段争用，该检查
undo_retention和 UNDO 表空间自动扩展策略，不是加索引能解决的 - ASH 中秒级尖峰无法被 AWR 捕获（AWR 默认 60 分钟采样），得用
v$active_session_history按sample_time和event过滤，配合p1/p2锁定物理块
