应使用awrgrpt.sql生成RAC全局AWR报告，因其跨GV$视图汇总所有在线实例数据，能体现GC等待、跨实例SQL分布等集群特性；awrrpti.sql仅面向单实例，无法反映全局负载。
用 awrgrpt.sql 生成 RAC 全局 AWR 报告
Oracle RAC 环境下，要反映整个集群（所有实例）的聚合负载，必须使用 awrgrpt.sql 脚本，而不是单实例用的 awrrpt.sql。后者只查当前连接实例的快照，awrgrpt.sql 才会跨 GV$ 视图汇总所有在线实例的数据。
执行前确认：sqlplus / as sysdba 登录的是 CDB root 或任意节点的实例均可，但脚本本身不依赖当前容器；RAC 所有实例必须处于 OPEN 状态且能被 GV$INSTANCE 查询到，否则缺失实例的快照将被跳过。
- 路径固定为：
@?/rdbms/admin/awrgrpt.sql（?自动展开为$ORACLE_HOME） - 报告格式仍选
html或text，无差异 - 时间范围选择逻辑与单实例一致，但列出的快照 ID 是集群维度的全局序号（来自
DBA_HIST_SNAPSHOT中INSTANCE_NUMBER = 0的记录） - 无需手动指定实例列表——脚本自动拉取当前活跃的所有实例
为什么 awrrpti.sql 不适合“全局”场景
awrrpti.sql 是为“指定单个实例”设计的，交互中必须输入 inst_num（如 1、2），它本质上仍是单实例报告，只是允许你切换目标实例。若在 RAC 中误用该脚本并只输一个实例号，得到的只是那个节点的局部视图，无法体现跨实例的锁争用、GC 等待、全局缓存热点等关键 RAC 问题。
常见误操作：看到脚本名带 i 就以为是“instance-aware”，实际它是“instance-specific”。真正需要全局视角时，i 后缀反而是干扰项。
- 想看 GC Buffer Busy 的分布？必须用
awrgrpt.sql，它在 Top Events 中合并显示所有实例的 GC 类等待 - 想分析跨实例的 SQL 执行分布？
awrgrpt.sql的 SQL Statistics 部分会按INST_ID分组统计 -
awrrpti.sql输出的 Load Profile 中 “Physical Reads” 是单实例值，不是集群总和
避免因实例状态导致报告数据不全
RAC 中某个实例临时宕机或未注册进 OCR，会导致 awrgrpt.sql 在生成时跳过它——这不是脚本错误，而是数据源真实缺失。此时报告顶部会明确提示：“Warning: Instance X was not included due to missing snapshots.”
验证方法：运行 SELECT INSTANCE_NAME, STATUS FROM GV$INSTANCE;，确保所有预期实例都返回 OPEN；再查 SELECT DISTINCT INSTANCE_NUMBER FROM DBA_HIST_SNAPSHOT WHERE SNAP_ID BETWEEN :begin AND :end;，确认目标时间段内各实例都有快照。
- 若发现某实例无快照，检查其 MMON 进程是否存活：
ps -ef | grep mmon - 检查该实例的
awr_pdb_autoflush_enabled参数（仅影响 PDB 层），但对 CDB/RAC 全局快照无影响 - 快照间隔默认 60 分钟，若需更高精度，可在所有实例统一调整：
EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(interval => 30);
生成后怎么看“全局性”是否生效
打开 HTML 报告，直接定位到 “Load Profile” 和 “Top 5 Timed Events” 两节。真正的全局报告会有两个特征：
- “DB Time” 数值显著高于任一单实例报告中的 DB Time（因为是累加值）
- “Top Events” 中出现
gc cr block busy、gc buffer busy acquire、enq: TX - row lock contention等带gc或跨实例语义的事件 - SQL Statistics 表头含
Inst ID列，且多行对应不同实例编号
如果这些都没出现，大概率是误用了 awrrpt.sql 或登录时连到了非 RAC 环境的 standalone 实例——RAC 全局报告不可能完全不体现集群交互开销。
