必须生成Per-Instance AWR报告，使用awrrpti.sql并指定各inst_id；DB CPU需结合cpu_count计算比率（>0.8预警）；SQL负载须查Instance Detail页分布；关注gc类等待及连接层负载均衡配置。
必须生成 Per-Instance AWR 报告，否则全是假象
默认 awrrpt.sql 生成的是汇总报告，所有实例数据揉在一起，根本看不出哪个节点在扛压。你看到 DB CPU 总和是 80%，但可能是节点1占 75%、节点2只占 5%——这种失衡在汇总里完全被抹平。
正确做法是用 awrrpti.sql（注意是 i，不是 awrrpt.sql），它专为多实例设计：
- 执行
@?/rdbms/admin/awrrpti.sql - 输入两个
inst_id（比如 1 和 2），不能只输一个 - 选 HTML 格式，后续对比更直观
OEM 用户可在「Compare Periods」里勾选 Per Instance，否则导出的仍是聚合视图。
看 CPU 负载不能只盯 DB CPU，要算比率
DB CPU 高 ≠ 节点过载。RAC 各节点物理 CPU 核数可能不同：节点1有 96 核，节点2只有 48 核，但两者 DB CPU 都是 4000 秒，显然节点2已饱和。
必须交叉比对：
- 查核数：
SELECT inst_id, value FROM gv$parameter WHERE name = 'cpu_count' - 查时段 DB CPU（秒）：
SELECT inst_id, round(value/1000000, 2) cpu_sec FROM gv$sysmetric_history WHERE metric_name = 'DB CPU' AND begin_time > SYSDATE-1/24 - 算比率：
cpu_sec / cpu_count—— 超过 0.8 就该预警
快照间隔太长（如 1 小时）会漏掉短时尖峰，生产环境建议设为 15–30 分钟。
SQL 级别负载分布得进 Instance Detail 页面看
AWR 报告里「SQL ordered by CPU Time」页是全实例合并统计，一条 SQL 在节点1跑 10 次、节点2跑 1 次，你也只能看到总耗时，无法定位偏斜。
真正要看的是：
- 点开某条高耗 SQL → 进入「Instance Detail」子页面
- 重点看
Executions、CPU Time (s)、Buffer Gets三列按inst_id的分布 - 若
px qc instance固定在节点1，而px server instance大量在节点2，但节点1 CPU 飙升，问题大概率在 QC 端串行逻辑（如 PL/SQL 处理、大排序），不是并行本身
快速验证：SELECT inst_id, executions, cpu_time/1000000 cpu_sec, buffer_gets FROM gv$sql WHERE sql_id = 'abc123xyz' ORDER BY inst_id
别忽略 RAC 特有等待事件和连接层配置
如果 Top 5 Timed Events 出现 gc cr multi block request、gc current block busy 或 enq: TX - row lock contention，说明负载不均衡根源不在 SQL，而在跨节点块争用或事务热点。
常见诱因：
-
gc cr multi block request单次等待 > 100ms → 私网延迟或丢包，不是数据库参数问题 - 某节点
Logons per Second突增 → 应用连接池未启用LOAD_BALANCE=ON，所有连接扎堆到一个 VIP - 应用 TNS alias 硬编码了
INSTANCE_NAME或直连某节点 VIP，绕过了服务端负载均衡
检查是否绑定：SELECT inst_id, service_name, COUNT(*) FROM gv$session GROUP BY inst_id, service_name —— 若某 service_name 只出现在一个 inst_id，就是人为固化了路由。
