Oracle表权限查询：为何必须使用DBA_TAB_PRIVS而非DBA_SYS_PRIVS
在Oracle数据库中进行表权限查询时，资深DBA都会直接选择 DBA_TAB_PRIVS 数据字典视图。为什么不是 DBA_SYS_PRIVS 呢？根本原因在于这两个视图的权限管理范畴完全不同。
DBA_SYS_PRIVS 专门记录系统级权限，例如 CREATE TABLE、DROP ANY TABLE 这类影响整个数据库环境的全局性权限。而针对具体数据库对象的访问权限，如“用户A是否拥有查询SCOTT用户EMP表的权限”这类精细化的对象级权限，则完整记录在 DBA_TAB_PRIVS 视图中。该视图的每条记录都明确展示了：被授权者（GRANTEE）、授权者（GRANTOR）、目标表（TABLE_NAME）以及具体的操作权限（PRIVILEGE）。
初学者常见的误区是试图在 DBA_SYS_PRIVS 中查找特定表的 SELECT 权限，结果必然无法找到。另一个典型错误是查询时遗漏 OWNER 条件，导致将不同模式下的同名表权限混合显示，造成查询结果不准确。
查询特定表的所有权限分配（包含授权选项与层级信息）
要全面掌握某张表的权限分配情况，以下查询是标准方法。关键注意事项：必须指定 OWNER 参数，即模式名称，否则可能检索到多个模式下同名表的所有权限，导致数据混乱。
SELECT GRANTOR, GRANTEE, PRIVILEGE, GRANTABLE, HIERARCHY FROM DBA_TAB_PRIVS WHERE OWNER = 'SCOTT' AND TABLE_NAME = 'EMP';
解析结果中的重要字段：GRANTABLE 字段若显示 YES，表示被授权者可将此权限再次授予其他用户，这在权限管控中是需要重点关注的标志。HIERARCHY 字段为 YES 则表示权限支持层级继承，但通常仅适用于 SELECT 等特定权限，且在启用细粒度访问控制（FGAC）的环境中才具有实际意义。
- 若仅需了解直接授权关系，可暂时忽略
HIERARCHY列。 GRANTEE（被授权者）可能是具体用户、角色或PUBLIC。当出现PUBLIC时需特别注意——这意味着数据库所有用户均拥有此权限，存在潜在安全风险需进行评估。- 权限名称本身不区分大小写，但表名和所有者（OWNER）默认以大写形式存储，除非建表时使用了双引号强制小写。
查询用户/角色拥有哪些表的权限
从用户或角色角度进行权限排查在实际工作中更为常见，特别是在安全审计或权限回收场景中。此时使用 GRANTEE 字段进行过滤最为便捷。
SELECT OWNER, TABLE_NAME, PRIVILEGE, GRANTABLE
FROM DBA_TAB_PRIVS
WHERE GRANTEE IN ('HR', 'APP_ROLE');
执行此查询时需特别注意以下几点：
- 此处查询结果仅显示直接授予该用户或角色的权限。若权限通过角色间接获得，
DBA_TAB_PRIVS视图不会自动展开。要了解角色成员最终可访问的表，必须结合ROLE_ROLE_PRIVS和DBA_ROLE_PRIVS进行递归查询。 GRANTEE值区分大小写，但Oracle默认将用户名和角色名以大写形式存储。若用户使用小写加双引号方式创建（如"testuser"），查询时必须精确匹配。- 某些权限容易被忽视，例如
REFERENCES。该权限允许用户在其他表创建指向本表的外键，虽不直接读写数据，但建立了数据依赖关系，在考虑对象删除或修改时是重要的依赖风险点。
权限查询无结果？优先排查这三个方面
如果查询未返回预期的权限记录，不要急于断定权限未授予。更常见的情况是查询条件不匹配。通常按以下顺序进行排查：
- 当前用户是否拥有查询字典视图的权限？ 查询
DBA_TAB_PRIVS需要SELECT ANY DICTIONARY或SELECT_CATALOG_ROLE等高级权限。若无权限，可尝试查询ALL_TAB_PRIVS（仅显示当前用户有权访问对象的授权信息）或USER_TAB_PRIVS（仅查询当前用户自身对象的权限）。 OWNER参数是否正确？ 此处应填写模式名称，不一定是管理员用户名。例如用户SCOTT拥有的表，OWNER应为'SCOTT'，而非'SYSTEM'。- 权限是否通过角色间接获得？
DBA_TAB_PRIVS仅记录直接授权。若权限先授予角色，用户再拥有该角色，则权限记录存储在ROLE_TAB_PRIVS中，需通过角色权限视图进行查找。
真正复杂的情况涉及跨角色的权限链路与对象权限的嵌套授予。此时要理清完整权限图谱，单靠单一视图远远不够。必须将 DBA_TAB_PRIVS、ROLE_TAB_PRIVS、DBA_ROLE_PRIVS 等视图关联查询，并特别注意角色间的循环授予问题，这可能引发查询结果重复甚至无限递归，需要妥善处理。
