DBA_TAB_PRIVS仅记录直接授权，不包含角色继承权限；需结合DBA_ROLE_PRIVS和ROLE_TAB_PRIVS追踪角色路径，并注意PUBLIC授权及大小写敏感问题。
查 DBA_TAB_PRIVS 只能看见直接授权
dba_tab_privs 是一张「显式授权快照表」，只记录 grant select on emp to alice 这类语句产生的行。它不会自动展开角色继承路径，比如 grant hr_role to alice → grant select on dept to hr_role。所以如果你在 dba_tab_privs 里查不到某用户对某张表的权限，不代表没权限——只是权限来自角色，这张表根本不会存那条记录。
常见错误现象：执行如下查询返回空，就以为用户没权限：
SELECT * FROM DBA_TAB_PRIVS WHERE GRANTEE = 'ALICE' AND TABLE_NAME = 'EMP';
其实该用户可能通过 HR_ROLE 拥有该权限，而 DBA_TAB_PRIVS 中对应行的 GRANTEE 字段值是 'HR_ROLE'，不是 'ALICE'。
用 DBA_ROLE_PRIVS + ROLE_TAB_PRIVS 追踪角色来源
要确认权限是否来自角色，必须分两步走：
- 先查用户被授予了哪些角色：
SELECT GRANTED_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'ALICE' - 再查这些角色各自有哪些对象权限：
SELECT ROLE, OWNER, TABLE_NAME, PRIVILEGE FROM ROLE_TAB_PRIVS WHERE ROLE IN (/* 上一步结果 */)
ROLE_TAB_PRIVS 只反映「角色被直接赋予的对象权限」，不递归嵌套（比如 MYROLE 被授给 OTHERROLE，而 OTHERROLE 有权限，ROLE_TAB_PRIVS 不会体现）。所以只要在 ROLE_TAB_PRIVS 里找到匹配行，就能闭环验证权限确实由该角色提供。
注意：DBA_TAB_PRIVS.GRANTOR 字段若显示角色名（如 'HR_ROLE'），通常意味着该权限是通过该角色间接授予的；但更稳妥的方式仍是联合查 DBA_ROLE_PRIVS 和 ROLE_TAB_PRIVS，避免误判 GRANTABLE = 'YES' 的情况。
PUBLIC 权限容易被忽略
GRANTEE = 'PUBLIC' 是一种特殊授权，所有用户默认隐式拥有，不依赖是否出现在 DBA_ROLE_PRIVS 中。如果某张表的权限记录里 GRANTEE 是 'PUBLIC'，那任意用户（包括新创建的）都能访问——哪怕你没查到该用户在任何角色或直授列表里。
容易踩的坑：
- 忘记加
OR GRANTEE = 'PUBLIC'条件，导致漏掉全局可访问对象 -
GRANTEE和ROLE字段大小写敏感，Oracle 默认大写，WHERE GRANTEE = 'alice'查不到，得写'ALICE' -
GRANTABLE = 'YES'表示权限可再转授，但它只对直接授权或带WITH GRANT OPTION的角色授权有效；普通角色继承来的权限，GRANTABLE恒为'NO'，不能反推来源
为什么不能只靠一个视图判断权限来源
Oracle 没有内置视图直接输出「用户 X 对表 Y 的全部有效权限及来源路径」。你看到的每一条权限记录，背后可能是：
- 直接授予：
DBA_TAB_PRIVS有记录，GRANTEE = 'ALICE' - 角色授予：
DBA_TAB_PRIVS无记录，但DBA_ROLE_PRIVS+ROLE_TAB_PRIVS能串起来 - PUBLIC 授权：
DBA_TAB_PRIVS有记录，但GRANTEE = 'PUBLIC'
最常被低估的复杂点是嵌套角色链（A→B→C→权限）和大小写一致性——一旦中间某层角色名大小写不匹配，整个链就断了。实际排查时，建议先统一用大写做字符串比对，再按需补全大小写处理逻辑。
