必须用 awrgrpt.sql，因其调用 AWR_GLOBAL_REPORT_HTML 实现跨实例快照拉取、时间对齐与统计合并；awrrpt.sql 仅读单实例 gv$ 视图，RAC 下无法捕获 gc 等跨实例等待事件。
直接用 @?/rdbms/admin/awrgrpt.sql，别碰 awrrpt.sql 或 awrrpti.sql —— 后两者只出单实例报告，RAC下跑它们等于白忙。
为什么必须用 awrgrpt.sql 而不是 awrrpt.sql
Oracle RAC 的全局报告和单实例报告是两套独立逻辑：awrrpt.sql 只读当前连接实例的 gv$ 视图子集，压根不跨实例聚合；awrgrpt.sql 才真正调用 DBMS_WORKLOAD_REPOSITORY.AWR_GLOBAL_REPORT_HTML，从所有节点拉取快照、对齐时间窗口、合并等待事件和 SQL 统计。实测中，同一组快照 ID 用 awrrpt.sql 和 awrgrpt.sql 分别跑，前者 TOP 5 Wait Events 里看不到跨实例锁（如 gc buffer busy acquire），后者会完整呈现。
- 脚本路径必须带
?（即@?/rdbms/admin/awrgrpt.sql），不能写死绝对路径，否则找不到内部依赖的awrinput.sql - 执行前必须确认所有 RAC 实例都处于 OPEN 状态（查
SELECT instance_name, status FROM gv$instance;），任一实例非 OPEN 会导致脚本卡在 “Enter value for dbid:” 且无报错 -
awrgrpt.sql不接受inst_num参数 —— 它自动遍历所有实例，强行传实例号会触发ORA-13784: invalid input parameter
快照 ID 必须严格对齐时间点
RAC 全局报告要求起始和结束快照在**所有实例上都存在且时间偏差 ≤ 5 分钟**。如果某个节点因故障漏采快照，awrgrpt.sql 会静默跳过该节点数据，但报告顶部会显示 “Warning: Instance X missing snapshots for requested range”，这个警告容易被忽略，导致误判为“集群整体负载低”。
- 查快照对齐性：运行
SELECT instance_number, MIN(begin_interval_time), MAX(end_interval_time) FROM dba_hist_snapshot WHERE snap_id BETWEEN &begin_snap AND &end_snap GROUP BY instance_number; - 安全做法：用
TRUNC(SYSDATE-1)这类确定性时间点反查快照，例如SELECT DISTINCT snap_id FROM dba_hist_snapshot WHERE begin_interval_time >= TRUNC(SYSDATE-1) AND begin_interval_time ，挑首尾两个 ID - 避免用 “最近 N 天” 交互式选范围 ——
awrgrpt.sql的交互逻辑默认只查当前实例的快照列表，其他节点的快照不会显示，极易选到不全的 ID 对
HTML 报告打不开图表？检查 $ORACLE_HOME/rdbms/admin 下的资源文件
生成的 awrgrpt_*.html 依赖同目录下的 awrrpt.css、awrrpt.js 和 awrddrpt.js。RAC 环境中常出现权限断裂：比如节点 1 生成报告时，oracle 用户对节点 2 的 $ORACLE_HOME/rdbms/admin 没有读权限，导致 CSS 加载失败，页面只剩文字表格。
- 验证方法：用
ls -l $ORACLE_HOME/rdbms/admin/awrrpt.*看文件权限，确保组和其他用户有r--（至少 644） - 临时修复：在生成报告的节点上，运行
chmod 644 $ORACLE_HOME/rdbms/admin/awrrpt.* - 浏览器必须用
file://协议以外的方式打开 —— 直接双击 HTML 文件会触发跨域限制，图表区域显示 “Failed to load chart data”。正确方式是起本地 HTTP 服务：cd $ORACLE_HOME/rdbms/admin && python3 -m http.server 8000，然后访问http://localhost:8000/awrgrpt_1_12345_12346.html
最易被忽略的点：RAC 全局报告里 “Load Profile” 和 “Instance Efficiency Percentages” 是各节点指标的简单平均值，不是加权汇总。如果你的两个节点负载严重不均（比如节点 1 承担 90% 请求），这些平均值会掩盖真实瓶颈，必须下钻到每个实例的 awrrpti.sql 报告单独分析。
