awrgrpt.sql是RAC全局AWR报告的唯一正确入口，因其调用AWR_GLOBAL_REPORT_HTML接口自动聚合所有实例数据；而awrrpt.sql仅查当前实例，无法显示gc等待等跨实例指标，易致分析失真。
必须用 awrgrpt.sql，不能用 awrrpt.sql —— 后者只生成单实例报告，rac下会漏掉其他节点数据，直接导致分析失真。
为什么 awrgrpt.sql 是 RAC 全局报告的唯一正确入口
Oracle 11g RAC 中，每个实例独立采集快照（WRH$_ 表按 instance_number 分区），但全局负载分析需合并所有实例的等待事件、SQL 执行、IO 分布。只有 awrgrpt.sql 脚本调用的是 DBMS_WORKLOAD_REPOSITORY.AWR_GLOBAL_REPORT_HTML（或 TEXT）接口，底层自动 JOIN 多个 gv$ 视图和跨实例历史表；而 awrrpt.sql 只查当前连接实例的 v$ 和本地 dba_hist_* 表。
常见错误现象：
– 用 awrrpt.sql 在 RAC 上生成报告，TOP 5 Timed Events 里看不到 “gc cr block busy” 或 “enq: TX – row lock contention” 等典型跨实例等待；
– 报告开头显示 “Instance: inst1”，但实际业务流量分布在 inst2/inst3，指标严重偏低。
awrgrpt.sql 执行前必须确认的三件事
脚本不校验环境，输错就报错或静默生成无效报告：
- 以
sqlplus / as sysdba连接，且当前实例是目标 RAC 数据库中的任意一个（不需要连特定实例，脚本内部会自动发现全部） -
DBID必须准确：执行SELECT dbid FROM v$database;查，别抄错（尤其末尾是数字0还是字母O） - 快照 ID 必须在所有实例上都存在：执行
SELECT DISTINCT snap_id FROM dba_hist_snapshot WHERE instance_number IN (SELECT instance_number FROM gv$instance) AND begin_interval_time > SYSDATE-2 ORDER BY snap_id;，挑成对的、时间连续的 ID（如 12345 和 12346）
参数顺序和交互式输入的坑
awrgrpt.sql 也是位置绑定参数，顺序错一个就失败：
标准调用格式：@?/rdbms/admin/awrgrpt.sql <report_type> <dbid> <num_days> <begin_snap> <end_snap>
关键点：
-
report_type只接受小写html或text，输HTML直接报SP2-0552 -
num_days仅用于交互式模式下自动列出快照；若已指定begin_snap/end_snap，填0即可，不填会卡在 “Enter value for num_days:” - RAC 下没有
inst_num参数位——这是awrrpti.sql用的，awrgrpt.sql固定作用于全部实例
生成后打不开 HTML 报告？重点检查这两处
报告文件生成成功 ≠ 能正常查看：
- 生成路径下的
awrrpt.css和awrrpt.js必须可读：检查$ORACLE_HOME/rdbms/admin/权限，常见 AIX/Linux 上因 umask=077 导致新 HTML 文件无法加载同目录资源 - 别双击打开
file://路径：浏览器会拦截跨域请求，图表区域显示 “Failed to load chart data”。正确做法是起本地服务：cd /u01; python3 -m http.server 8000，然后访问http://localhost:8000/awrrpt_12345_12346.html
真正容易被忽略的是：RAC 全局报告依赖所有实例的 SYSAUX 表空间都在线且未只读。如果某个实例因故障挂起、其 SYSAUX 不可用，awrgrpt.sql 仍会生成报告，但对应实例的数据段全为空白——得去 dba_hist_snapshot 里逐个核对各实例的快照状态。
