判断RAC节点负载是否均衡需交叉比对AWR中“RAC Statistics”里的gc cr/current blocks received/served、Interconnect流量及gv$sysstat实时GC分布，结合service_name连接分布与隐藏指标如gc receive time、global enqueue get time等综合分析。
怎么看 RAC 节点间负载是否均衡（直接看 AWR 报告里的 Global Cache 和 Interconnect 指标）
awr 报告本身不提供“负载均衡度”百分比，得靠交叉比对几个关键指标来判断。重点不是单看 cpu 或会话数，而是看节点间协同开销是否异常——比如某个节点频繁当“中转站”，自己没干多少活，却在大量收发 gc cr block 2-way 或 gc current block busy。
实操建议：
- 打开 AWR 报告 → 翻到 “RAC Statistics” 部分（不是“Instance Activity Stats”），这里才有节点级的全局缓存统计
- 重点关注每节点的
gc cr blocks received、gc current blocks received、gc cr blocks served、gc current blocks served四个值：接收多但服务少，说明它在“吃资源等别人送数据”；服务多但接收少，说明它在“扛主力被其他节点频繁请求” - 再对照 “Interconnect Traffic per Second” 表格，看各节点的
Bytes sent和Bytes received是否严重偏离均值（比如某节点发送量是其他节点的 3 倍以上）
gv$sysstat 查实时 GC 流量分布（比 AWR 更快定位抖动）
AWR 是快照汇总，滞后性强。真要查“现在哪个节点正被疯狂拉数据”，得上 gv$sysstat 实时查。注意必须用 gv$ 视图，否则只看到当前实例的数据，漏掉跨节点关系。
常见错误现象：写 SQL 时漏加 inst_id 过滤，结果把所有节点数据 sum 在一起，误判为“整体平稳”，实际是 A 节点狂发、B 节点狂收，互相抵消了。
实操建议：
- 运行以下语句（替换
begin_snap和end_snap为对应 AWR 快照 ID，或去掉 where 条件查当前值）：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') ORDER BY inst_id, name; - 对比各节点的
received总和 vsserved总和：理想情况二者应大致相等（请求和响应守恒）。若某节点received > served显著偏高，说明它依赖其他节点供数，自身可能 CPU/IO 不足或 SQL 绑定不均 - 别只盯绝对值——算标准差：如果 4 节点的
gc cr blocks received分别是 100k / 95k / 110k / 20k，那第 4 节点就是异常点，不是看平均值，是看离散度
为什么 service_name 和 client_info 比节点名更重要
很多人盯着 inst_id=1 和 inst_id=2 的数字差，却忽略真正驱动流量的是客户端连接行为。RAC 负载不均，90% 源于应用层没配好 TAF、没设 LOAD_BALANCE=on，或 service 绑定到了固定实例。
使用场景：当你发现 AWR 里节点 A 的 gc cr blocks received 是 B 的 5 倍，但 v$session 里 A 的活跃会话反而更少——大概率是某些 service 全打到 A，而这些 session 正在做大量跨节点一致性读。
实操建议：
- 查当前连接分布：
SELECT service_name, inst_id, COUNT(*) cnt FROM gv$session WHERE status = 'ACTIVE' GROUP BY service_name, inst_id ORDER BY service_name, inst_id;
- 检查 service 配置：
srvctl config service -d <db>，确认Preferred和Available列是否合理，有没有 service 被硬编码到单节点 - 别信客户端连的 IP：Oracle 客户端连的是 SCAN VIP，背后路由由 LBA（Load Balancing Advisory）决定，而 LBA 又依赖
DBMS_SERVICE.GET_SERVICE_GOAL和实例负载指标。所以必须查gv$active_services里的current_active_sessions和goal字段
AWR 报告里容易被忽略的三个隐藏信号
很多 DBA 只扫一眼“Top 5 Timed Events”，但 RAC 均衡性问题常藏在更底层的统计差异里。这三个字段不显眼，但一有偏差，基本坐实非均衡。
性能影响：它们反映的是 interconnect 层的真实压力，一旦失衡，即使 CPU 使用率看起来正常，也会因网络等待拖慢整体 TPSS。
实操建议：
-
gc cr block receive time和gc current block receive time：单位是毫秒，若某节点这两项均值 > 5ms（千兆网环境），且比其他节点高 2 倍以上，说明该节点网卡、交换机端口或 OS 网络栈可能有瓶颈，不是数据库配置问题 -
global enqueue get time：这个时间包含锁争用 + 网络延迟。如果某节点此项突增，但enq: TX - row lock contention并不高，大概率是它频繁跨节点申请资源，成了“锁中转站” -
physical reads cache和physical reads direct的比例：若某节点 direct 读远高于其他节点，说明它的 buffer cache 命中率崩了，被迫绕过 cache 直接读盘，进而触发更多 global cache 请求去拉别人 cache 里的块
复杂点在于：这些指标之间互为因果。比如 interconnect 延迟升高 → gc receive time 上升 → 应用等待加剧 → 连接堆积 → service 路由失效 → 更多请求打到同一节点。所以不能孤立看一个数，得像查案一样串起来看链路。
