查不到GRANT记录是因为审计未启用或配置错误：AUDIT_TRAIL需设为DB/DB,EXTENDED，对象权限需AUDIT GRANT ANY OBJECT PRIVILEGE，普通用户操作需在审计策略内，SYS操作需AUDIT_SYS_OPERATIONS=TRUE；统一审计更优，需创建并启用策略，查UNIFIED_AUDIT_TRAIL。
查不到GRANT记录？先确认审计是否真正启用
执行完 GRANT SELECT ON hr.employees TO alice 后查 DBA_AUDIT_TRAIL 为空，大概率不是漏操作，而是审计根本没生效。关键检查点有三个：
-
AUDIT_TRAIL参数必须是DB或DB,EXTENDED，NONE下所有AUDIT命令都无效——用SHOW PARAMETER audit_trail立刻验证 - 只执行
AUDIT GRANT ANY PRIVILEGE不够：它捕获系统权限授予（如GRANT CREATE TABLE TO scott），但对象权限（如上例）必须额外执行AUDIT GRANT ANY OBJECT PRIVILEGE - 普通用户执行的
GRANT不会进DBA_AUDIT_TRAIL，除非该用户在审计策略覆盖范围内；SYS/SYSDBA 操作默认不记录，必须开启AUDIT_SYS_OPERATIONS=TRUE并重启实例
统一审计（Unified Audit）才是生产环境首选
Oracle 12c+ 应优先用统一审计，它性能更好、字段更全、无需重启即生效，且默认启用视图 UNIFIED_AUDIT_TRAIL。但注意它不会自动记录——得手动建策略：
- 创建策略：
CREATE AUDIT POLICY grant_policy ACTIONS GRANT, REVOKE——ACTIONS GRANT已覆盖系统权限、对象权限、角色授权，不用分项配置 - 启用策略：
AUDIT POLICY grant_policy - 查记录：直接查
UNIFIED_AUDIT_TRAIL，字段ACTION_NAME = 'GRANT'，OBJECT_SCHEMA/OBJECT_NAME明确指向被授权对象，SQL_TEXT包含完整语句 - 若已启用预定义策略
ORA_SECURECONFIG（默认开启），它已包含GRANT审计，可跳过建策步骤
DBA_ROLE_PRIVS 只反映快照，不等于权限变更日志
想靠 SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'ALICE' 找出“谁什么时候把 DBA 授给了她”，注定失败。这张表只存当前状态，不带时间戳，也不记录操作者。
- 查当前谁有 DBA 角色：必须用
DBA_ROLE_PRIVS WHERE GRANTED_ROLE = 'DBA'，别用USER_ROLE_PRIVS（只返回当前会话可见角色） -
ADMIN_OPTION = 'YES'表示该用户能把 DBA 再授给别人，这是高危信号，需重点盯住 - 真正要追溯变更时间，只能依赖审计——标准审计查
DBA_AUDIT_TRAIL（字段NTIMESTAMP#），统一审计查UNIFIED_AUDIT_TRAIL（字段EVENT_TIMESTAMP） - 别忽略
V$PWFILE_USERS：SYSDBA = 'TRUE'的用户能绕过所有角色机制直接登录并授予权限，其操作必须通过AUDIT_SYS_OPERATIONS捕获到 OS 日志里
权限来源≠权限变更，别混用两个问题
查 DBA_TAB_PRIVS 发现用户没权限，不等于权限被 revoke 过——更可能是权限来自角色嵌套或 PUBLIC，而你没递归展开。
-
DBA_TAB_PRIVS只存显式GRANT记录，不展开角色继承链；用户通过角色获得权限时，GRANTEE字段是角色名，不是用户名 - 要还原完整来源，得串查三张表：
DBA_ROLE_PRIVS（用户有哪些角色）→DBA_TAB_PRIVS（这些角色有哪些表权限）→ 再叠加用户直接受权记录 - 如果真要定位“最后一次变更”，唯一可靠路径是审计日志：统一审计里每条
GRANT记录自带EVENT_TIMESTAMP和DBUSERNAME，能精确到毫秒级
审计策略一旦启用，记录写入就有延迟或异步行为，尤其在高负载下；UNIFIED_AUDIT_TRAIL 虽比 DBA_AUDIT_TRAIL 更及时，但也不是实时。查不到最新记录时，先等几秒再查，别急着调参数。
