oracle 11g rac负载不均衡诊断应聚焦gc流量对称性，关键看awr中gc cr/current blocks received/served四指标按inst_id分实例比对，标准差分析比均值更有效，需结合iftop验证真实udp流量、跨节点延迟及缓存配置一致性。
Oracle 11g RAC节点间负载不均衡，不能只看 DB CPU 或 logons current —— 这些指标掩盖了真正的协同失衡。核心诊断点在全局缓存（GC）流量分布是否对称，关键指标全集中在 AWR 报告的 RAC Statistics 部分。
重点盯这四个 GC 块统计项
AWR 报告里「Instance Activity Stats」是误导性最强的地方。真正暴露节点角色失衡的，是 gc cr blocks received、gc current blocks received、gc cr blocks served、gc current blocks served 这四列，必须按实例（inst_id）单独比对：
- 某节点
gc cr blocks received显著高于其他节点，但gc cr blocks served很低 → 它在被动拉取一致性读块，本地 buffer 不足或 SQL 绑定不均 - 某节点
gc current blocks served独占 80%+，而接收量极小 → 它是热点数据持有者，比如序列号表、高频更新的配置主表 - 四列总和应基本平衡：
received总和 ≈served总和；若偏差 >15%，说明有节点长期充当“中转站”而非计算节点 - 标准差比平均值更有意义：4 节点的
gc cr blocks received若为 92k / 98k / 101k / 21k，第 4 节点就是异常点，不是“略低”，而是“几乎不参与 GC 协同”
别信 Interconnect Traffic per Second 表格
这个表格里的字节数是 Oracle 用默认 8KB × 块数硬算出来的估算值，实际线缆流量含 IP/UDP/以太网头部，高估 15%–20%，且混杂 CSSD 心跳、OCR 同步等非 GC 流量，完全不能反映 GC 负载偏斜。
- 真实验证方法：在每个节点上跑
iftop -P udp -f "host 169.254.x.x and host 169.254.y.y"，盯住双向速率是否严重偏离均值（如某节点发送速率达其他节点 3 倍以上） - 查实时 GC 分布：执行
SELECT inst_id, name, value FROM gv$sysstat WHERE name IN ('gc cr blocks received','gc current blocks received','gc cr blocks served','gc current blocks served')，务必带inst_id，否则SUM()会把所有节点合并，彻底掩盖问题
交叉验证：GC 流量高 ≠ 性能差，得看等待和延迟
GC 块收发量大本身不构成瓶颈，只有当它引发等待恶化或延迟升高时才真有问题。
- 检查
gc buffer busy acquire、gc cr block busy是否同步进入 Top 5 Timed Events，且集中在某节点 - 查跨节点延迟：运行
SELECT inst_id, event, time_waited_micro/1000000 sec FROM gv$session_event WHERE event LIKE 'gc%' AND time_waited_micro > 0 ORDER BY time_waited_micro DESC，看某节点是否存在毫秒级延迟尖峰 - 对比
gv$system_event中各节点的gc cr block 2-way平均等待时间，若某节点高出 2 倍以上，说明 interconnect 或远程节点响应已拖慢整体
最容易被忽略的是：AWR 快照间隔设为 1 小时，会直接抹掉短时 GC 激增（比如批量作业启动瞬间），生产环境建议固定为 15–30 分钟；另外，gc cr blocks received 异常高，有时根本不是应用问题，而是某节点 db_cache_size 被意外调小，导致频繁跨节点拉块——得顺手查 gv$parameter 里各节点缓存配置是否一致。
