SELECT ANY TABLE权限不覆盖系统表和数据字典视图，默认无法查询SYS对象、DBA_视图、V$视图及AUD$等，需显式授予SELECT ANY DICTIONARY或特定权限。
SELECT ANY TABLE 权限不覆盖系统表和数据字典视图的默认访问控制
拥有 SELECT ANY TABLE 的用户仍可能查不到某些表，最常见原因是：该权限只允许访问“普通用户表”，但对 SYS 模式下的核心对象（如 SYS.OBJ$、SYS.USER$）以及部分动态性能视图（如 V$SESSION、V$LOCK）无效。这些对象受独立的权限模型约束——必须显式授予 SELECT ANY DICTIONARY 或直接对具体视图授权。
-
SELECT ANY TABLE无法查DBA_USERS、DBA_TABLES等数据字典视图，报错ORA-00942；需额外授SELECT ANY DICTIONARY或SELECT_CATALOG_ROLE - 即使有
SELECT ANY TABLE，也无法绕过V$视图的会话级限制：这些视图只返回当前连接用户能看见的数据行（如V$SESSION默认只显示本会话），不是权限问题，而是设计行为 - 某些系统表（如
SYS.AUD$）被 Oracle 显式设为“不可查询”，即使 DBA 用户也需启用审计选项或使用DBMS_AUDIT_MGMT包访问，SELECT ANY TABLE完全无效
同义词或视图定义中的对象不可见
用户执行 SELECT * FROM v_emp成功，但查 v_emp 底层依赖的 hr.employees 却报 ORA-00942——这说明 v_emp 是用 DEFINER'S RIGHTS 创建的，权限检查发生在定义者（如 HR）上下文，而非调用者。但若用户尝试直接访问 hr.employees，就触发自己的权限检查，而 SELECT ANY TABLE 并未被用于此路径。
- 确认视图定义：
SELECT text FROM all_views WHERE owner = 'HR' AND view_name = 'V_EMP' - 检查视图依赖的所有对象是否真实存在且可被当前用户解析（例如
hr.employees表是否存在、是否被重命名、是否在回收站中） - 私有同义词（
USER_SYNONYMS）只对创建者有效；跨用户访问必须用公有同义词或全限定名，否则解析失败
PL/SQL 中角色权限不生效
在存储过程、函数或匿名块里执行动态 SQL（如 EXECUTE IMMEDIATE 'SELECT * FROM hr.employees'）时，即使用户拥有 SELECT ANY TABLE，也可能因角色未激活而失败——因为 PL/SQL 默认不启用通过角色授予的系统权限（包括 SELECT ANY TABLE），只认直接授予的权限。
- 验证方式：在 SQL*Plus 中运行
SET ROLE NONE;后再试查询，如果立刻报错，说明此前依赖的是角色权限 - 修复方法：把
SELECT ANY TABLE直接授予用户（而非通过角色），或改用DEFINER'S RIGHTS存储过程并确保定义者有对应权限 - 注意：
SELECT ANY TABLE本身不能通过角色间接授予（它是系统权限，不是对象权限），但如果用户是通过某个角色获得该权限，则该角色在 PL/SQL 中仍不生效
权限被显式拒绝（REVOKE）或受限于容器/租户
Oracle 多租户（CDB/PDB）环境下，SELECT ANY TABLE 只在当前 PDB 内有效；若表位于另一个 PDB，或用户连接的是 CDB$ROOT，权限范围自动受限。另外，DBA 可能对特定 schema 执行了 REVOKE SELECT ON schema.t FROM PUBLIC 或类似操作，形成“显式拒绝”覆盖“ANY”权限。
- 检查当前容器：
SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL - 确认目标表所在容器：
SELECT con_id, owner, table_name FROM cdb_tables WHERE table_name = 'EMPLOYEES' - 显式拒绝极难排查，需查
DBA_TAB_PRIVS中GRANTABLE = 'NO'且PRIVILEGE = 'SELECT'的记录，再结合REVOKE历史审计日志
真正麻烦的从来不是“有没有权限”，而是“权限在哪个上下文里生效”。SELECT ANY TABLE 看似万能，实则处处受限——它不穿透容器边界、不激活角色、不覆盖显式拒绝、也不触达系统核心对象。别把它当钥匙，它更像一张只在特定楼层有效的门禁卡。
