awrrpt.sql执行失败主因是连接未建立、路径错误或依赖包失效；需先sqlplus / as sysdba登录再执行脚本，检查dbms_workload_repository等包状态，rac环境须确认实例号匹配，报告不可用还可能源于css/js文件权限或浏览器策略。
不能执行 awrrpt.sql，大概率不是权限不够，而是脚本根本没跑起来——SYS 用户连不上、路径不对、依赖包失效，三者占九成。
ORA-01017 或卡在 Enter value for dbid: 就停住
这是最典型的“没连上就开跑”现象。awrrpt.sql 是 SQL*Plus 脚本，不自动连接数据库，也不继承当前会话上下文。
- 必须先用
sqlplus / as sysdba连进实例，再执行@?/rdbms/admin/awrrpt.sql；用普通sqlplus username/password或未加as sysdba都会触发 ORA-01017 - 如果数据库是 RAC，且你连的是某个实例（比如
sqlplus /@inst1 as sysdba），但脚本里选了另一个inst_num，也会卡在 DBID 输入环节 - 别在非 SYS 模式下尝试切换用户：SQL*Plus 不支持
CONNECT后再跑@awrrpt.sql——它会把 CONNECT 当作报告参数的一部分解析
SP2-0310: unable to open file "awrrpti.sql" 或 ORA-04063 包体错误
这两个错误表面不同，根源一致：DBMS_WORKLOAD_REPOSITORY 或其底层依赖（如 DBMS_SWRF_REPORT_INTERNAL）处于 INVALID 状态。
- 先查状态：
SELECT object_name, status FROM dba_objects WHERE owner = 'SYS' AND object_name IN ('DBMS_WORKLOAD_REPOSITORY', 'DBMS_SWRF_REPORT_INTERNAL') AND status != 'VALID'; - 不要只试
ALTER PACKAGE ... COMPILE——若报PLS-00753: malformed or corrupted wrapped unit，说明包体已损坏，需重装 - 按顺序执行以下脚本（必须用
/ as sysdba）：@?/rdbms/admin/catawrtb.sql→@?/rdbms/admin/dbmsawr.sql→@?/rdbms/admin/prvtawr.plb→@?/rdbms/admin/utlrp.sql - 最后重启实例（
shutdown immediate; startup;）再试，否则新编译的包可能未被完全加载
RAC 环境下报多个实例、选错 inst_num 导致报告为空
迁移或重装后，dba_hist_snapshot 里常残留旧主机名和实例记录，脚本会列出所有历史实例，但只对当前有效的 inst_num 生成数据。
- 运行脚本前先确认当前实例号：
SELECT instance_number, instance_name, host_name FROM gv$instance; - 检查快照是否归属当前实例：
SELECT DISTINCT instance_number FROM dba_hist_snapshot WHERE snap_id BETWEEN 1000 AND 1010;（挑两个近期快照 ID） - 如果发现快照里有旧
instance_number（比如显示 2，但当前只有 inst1 在线），说明 AWR 元数据未清理干净，需手动修正或重建控制文件级信息（谨慎操作） - 单机环境也别硬填
1：用SELECT instance_number FROM v$instance;查实，避免因 RAC 残留配置导致静默失败
真正容易被忽略的点是：脚本执行成功 ≠ 报告可用。生成的 HTML 文件若打不开、图表空白，问题往往出在 $ORACLE_HOME/rdbms/admin/ 下的 CSS/JS 文件权限或浏览器跨域策略上，跟 SYS 权限无关——得去文件系统和浏览器里查，不是改数据库就能解决的。
