授予SELECT ANY DICTIONARY前须确认：执行者拥有GRANT ANY PRIVILEGE权限或为具备该权限的DBA；仅限运维监控等必要场景；优先选用更安全的SELECT_CATALOG_ROLE或细粒度授权。
授予 SELECT ANY DICTIONARY 角色前必须确认的事
这个角色不是“查所有表”的快捷方式，而是直接绕过数据字典视图的访问控制——它允许用户执行 select * from dba_tables、select * from dba_users 这类高权限查询。oracle 默认不给任何普通用户，连 dba 角色都不自动包含它，因为一旦启用，就等于暴露整个数据库结构、参数、审计配置甚至密码哈希（如 dba_users.password 在旧版本中）。
常见错误现象：ORA-00942: table or view does not exist 出现在查 DBA_* 视图时，不是因为视图不存在，而是当前用户没被显式授权或没被授予 SELECT ANY DICTIONARY。
- 只在真正需要运维、监控或诊断工具集成时才授，比如部署 Oracle Enterprise Manager Agent 或自研巡检脚本
- 不能替代细粒度授权（例如只查
ALL_TAB_COLUMNS就不该给DBA_TAB_COLUMNS权限） - 12c 及以后版本中，
SELECT_CATALOG_ROLE是更安全的替代选项，它只覆盖常用ALL_*和部分DBA_*视图，不含敏感字段
用 GRANT 命令授予权限时的硬性前提
执行授权的人必须拥有 GRANT ANY PRIVILEGE 系统权限，或者本身就是 DBA（且该 DBA 角色本身已被授予 GRANT ANY PRIVILEGE）。普通 DBA 用户如果没有这个权限，执行 GRANT SELECT ANY DICTIONARY TO user_a 会报 ORA-01031: insufficient privileges。
使用场景：通常由数据库管理员（非应用账号）在 SQL*Plus 或 SQL Developer 中操作，不建议写进应用初始化脚本。
- 命令必须以具有足够权限的用户（如
SYS AS SYSDBA）连接后执行 - 语法是
GRANT SELECT ANY DICTIONARY TO <username>，不能加WITH ADMIN OPTION给普通用户——这会导致权限扩散失控 - 如果目标用户已锁定或过期，授权仍成功，但实际无法登录使用该权限
SELECT ANY DICTIONARY 和 SELECT_CATALOG_ROLE 怎么选
二者都能查数据字典，但行为和范围差异很大。前者是系统权限，后者是预定义角色；前者生效立即全局可见，后者需额外 SET ROLE 才能激活（除非默认启用）。
性能/兼容性影响：无直接性能差异，但 SELECT_CATALOG_ROLE 在 Oracle 12cR2+ 中被标记为“legacy”，官方文档建议新系统优先用细粒度授权（如 GRANT SELECT ON SYS.DBA_TABLES TO user_a），避免角色隐式依赖。
-
SELECT ANY DICTIONARY：可查全部DBA_*、ALL_*、USER_*视图，包括DBA_AUDIT_TRAIL、DBA_ENCRYPTION_KEYS等敏感视图 -
SELECT_CATALOG_ROLE：仅覆盖约 60 个常用视图，不含审计原始记录、加密密钥、ASM 相关等高危视图 - 检查当前用户有哪些权限：查
SESSION_ROLES看角色，查SESSION_PRIVS看系统权限
授完权限后查不到 DBA_* 视图？先看这三处
不是授权失败，就是环境卡点。最常被忽略的是会话上下文没刷新，或者对象名大小写/拼写出错。
常见错误现象：执行 SELECT COUNT(*) FROM DBA_TABLES 仍报 ORA-00942，但 SELECT * FROM USER_TABLES 正常。
- 确认是否在正确容器中：CDB 环境下，
DBA_*视图默认只在 root 容器可见，PDB 中需切换到CDB$ROOT或使用CDB_*视图 - 检查当前会话是否已重新连接：授权后新建会话才能生效，旧会话不会自动加载新权限
- 验证视图是否存在且拼写准确：
SELECT * FROM DICT WHERE TABLE_NAME LIKE '%TABLE%'查可用字典视图名，注意DBA_TABLES不是DBA_TABLE
复杂点在于权限生效路径长：系统权限 → 字典视图定义 → 视图底层基表权限 → 实际执行时的解析权限。容易被忽略的是 CDB/PDB 切换和会话复用问题——很多自动化脚本连一次都不重连，就一直查不到。
