生成AWR报告需要SELECT ANY DICTIONARY权限，因为awrrpt.sql脚本依赖DBA_HIST_、WRH_等数据字典视图，而这些视图仅对SYS或拥有该权限的用户开放；普通DBA角色不包含此权限，导致ORA-00942等错误。
为什么生成AWR报告需要 SELECT ANY DICTIONARY？
因为 awrrpt.sql 脚本在后台大量依赖 dba_hist_*、wrh$_* 等数据字典视图（如 dba_hist_sqlstat、dba_hist_sysmetric_summary），而这些视图默认只对 sys 或拥有 select any dictionary 权限的用户开放。普通 dba 角色不自动包含该权限——这是很多人执行 @?/rdbms/admin/awrrpt 时突然报 ora-00942: table or view does not exist 的根本原因。
如何安全授予诊断权限（非SYS用户）
不要直接给应用账号或开发账号授权，应创建专用诊断账号并最小化授权：
- 用
SYS登录：sqlplus / as sysdba - 创建只读诊断用户（示例名
awr_reader）：CREATE USER awr_reader IDENTIFIED BY "StrongPass123!" DEFAULT TABLESPACE users QUOTA 1M ON users;
- 授予必要权限（仅限读取，不含修改/删除）：
GRANT CONNECT TO awr_reader;<br>GRANT SELECT ANY DICTIONARY TO awr_reader;<br>GRANT SELECT ON dba_hist_wr_control TO awr_reader;
- 验证是否能查核心视图：
SELECT snap_interval, retention FROM dba_hist_wr_control;
（非SYS用户必须能查此视图才能运行awrrpt.sql）
常见错误现象与绕过陷阱
授了 DBA 角色却仍失败？这是因为 DBA 角色默认不包含 SELECT ANY DICTIONARY（从 12c 起更严格）。典型报错包括：
-
ORA-00942: table or view does not exist→ 实际是查WRH$_LATCH等基表失败 -
ORA-01031: insufficient privileges→ 在调用DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML时触发 - 脚本卡在“选择快照范围”步骤后无响应 → 很可能因权限不足导致内部查询超时
注意：SELECT_CATALOG_ROLE 不足以替代 SELECT ANY DICTIONARY，它不覆盖 WRH$_* 和 WRI$_* 等 AWR 特有基表。
能不能不用这个权限？替代方案有哪些
可以，但代价明确：
- 用
SYS或SYSTEM直接生成 → 安全策略通常禁止日常使用高权限账号 - 用
AWRSQRPT（按 SQL_ID 生成单条SQL报告）→ 仍需同等级权限，且无法替代全库分析 - 导出 ASH 数据再本地分析 → 需要
SELECT ON V_$ACTIVE_SESSION_HISTORY等单独授权，且丢失 AWR 的聚合统计维度（如 Load Profile、Efficiency Percentages）
真正省权限的做法不是绕开，而是把授权收束到一个可控账号，并限制其登录方式（比如只允许从 DBA 工作机 IP 连接）——否则，为图省事直接 GRANT SELECT ANY DICTIONARY TO PUBLIC，等于把数据库的血管图贴在防火墙上。
