dba_tab_privs仅记录直接授权，不包含角色继承权限；查用户完整权限需联合dba_tab_privs、dba_role_privs及处理public，且注意大小写与grantable字段含义。
查不到某个用户对某张表的权限，不是权限没授，而是 dba_tab_privs 只存直接授权，不展开角色继承——你得先分清权限来源类型，再选对视图和连接方式。
为什么直接查 DBA_TAB_PRIVS 会漏掉角色来的权限
DBA_TAB_PRIVS 是一张「显式授权快照表」：只记录 GRANT SELECT ON emp TO alice 这类语句产生的行。它不会自动关联 DBA_ROLE_PRIVS，也不会递归展开 GRANT hr_role TO alice → GRANT SELECT ON dept TO hr_role 这样的路径。
-
GRANTEE字段显示的是角色名（如'HR_ROLE'），不是用户名（如'ALICE'） - 如果用户通过角色获得权限，
DBA_TAB_PRIVS里根本查不到该用户名的记录 -
PUBLIC作为特殊GRANTEE，常被忽略，但它意味着任意用户都能访问该对象
怎么区分权限是直接授予还是来自角色
必须把 DBA_TAB_PRIVS 和 DBA_ROLE_PRIVS 对着看，不能只盯一张表。
- 查用户直接受到的表权限：
SELECT OWNER, TABLE_NAME, PRIVILEGE, GRANTOR FROM DBA_TAB_PRIVS WHERE GRANTEE = 'ALICE' - 查用户拥有的角色：
SELECT GRANTED_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'ALICE' - 查这些角色各自有哪些表权限：
SELECT OWNER, TABLE_NAME, PRIVILEGE, GRANTOR, GRANTEE AS VIA_ROLE FROM DBA_TAB_PRIVS WHERE GRANTEE IN (SELECT GRANTED_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'ALICE') - 若结果中某条记录的
GRANTEE是角色名，而该角色又出现在上一步的GRANTED_ROLE列里，那就是角色来源；否则就是直接授予
容易踩的坑：GRANTABLE、PUBLIC 和大小写敏感
权限来源判断错，往往卡在三个细节上：
-
GRANTABLE = 'YES'表示该权限可再转授，但这个字段只对直接授权或带WITH GRANT OPTION的角色授权有效；普通角色继承来的权限，即使能用，GRANTABLE也恒为'NO' -
GRANTEE = 'PUBLIC'的记录必须单独捞出来比对——它不依赖用户是否在DBA_ROLE_PRIVS里，所有用户默认隐式拥有 - Oracle 默认用户名、角色名全大写：
WHERE GRANTEE = 'alice'查不到，必须写'ALICE'；'connect'和'CONNECT'是两个不同角色
想看到完整权限链？别指望单条 SQL 自动递归
Oracle 没有内置视图能把「用户 → 角色 → 角色 → 表权限」一次性展开。你得手动拼 UNION ALL 或写递归子查询，而且嵌套超过两层就容易性能骤降。
- 生产环境一般只追 1–2 层足够：用户 → 直接角色 → 这些角色的表权限
- 真要查三层（比如角色 A 含角色 B，B 再含表权限），得用
ROLE_ROLE_PRIVS关联DBA_ROLE_PRIVS，再套进DBA_TAB_PRIVS，SQL 会变长且难维护 - 注意
DBA_TAB_PRIVS不记录权限是否启用，只记录是否授予；角色是否生效，还得看会话当前是否激活（参考SESSION_PRIVS和DEFAULT_ROLE）
最易被忽略的一点：哪怕你把三张视图都连上了，DBA_TAB_PRIVS 仍不体现 PUBLIC 权限的“间接性”——它就静静躺在那里，GRANTEE = 'PUBLIC'，不声不响地让所有人可用。漏掉这一行，等于漏掉一半权限真相。
