dba_role_privs查不到刚执行的grant dba记录，是因为标准审计默认不捕获该操作；需启用audit_sys_operations=true或使用统一审计（如ora_secureconfig策略）才能捕获。
为什么DBA_ROLE_PRIVS里查不到刚执行的GRANT DBA记录
不是数据没写进去，而是标准审计默认根本不捕获GRANT DBA TO这类操作。即使AUDIT_TRAIL=DB已启用，DBA_ROLE_PRIVS视图只反映当前授权状态，不记录变更过程；而审计表DBA_AUDIT_TRAIL也不会出现这条记录——除非你额外启用了AUDIT_SYS_OPERATIONS=TRUE。
常见误判是：看到GRANT DBA TO alice执行成功，立刻查DBA_AUDIT_TRAIL为空，就以为审计失效。其实根本原因是SYS/SYSDBA级操作被标准审计机制屏蔽了。
-
AUDIT_SYS_OPERATIONS=FALSE（默认值）时，所有以AS SYSDBA或AS SYSOPER身份执行的GRANT/REVOKE都不会进数据库审计表 - 必须用
ALTER SYSTEM SET AUDIT_SYS_OPERATIONS = TRUE SCOPE=SPFILE并重启实例，才能让这类操作写入操作系统审计文件（路径由AUDIT_FILE_DEST决定） - 查OS审计文件需登录数据库服务器，且文件名格式为
ora_<pid>.aud</pid>，不能用SQL直接查询
统一审计下怎么精准捕获GRANT/REVOKE语句
Oracle 12c+推荐用统一审计（Unified Auditing），它天然支持捕获所有权限变更，包括系统权限、对象权限、角色授予与回收，且无需分项配置。
关键不是创建新策略，而是确认是否已启用预定义策略ORA_SECURECONFIG——该策略从12.1起默认激活，包含ACTIONS GRANT, REVOKE规则，覆盖全部权限操作。
- 检查是否启用：
SELECT * FROM UNIFIED_AUDIT_TRAIL WHERE ACTION_NAME IN ('GRANT', 'REVOKE') AND ROWNUM = 1；若报ORA-00942，说明未启用Unified Auditing（需relink并重启） - 确认策略状态：
SELECT POLICY_NAME, ENABLED FROM AUDIT_UNIFIED_ENABLED_POLICIES；若ORA_SECURECONFIG不在结果中，执行AUDIT POLICY ORA_SECURECONFIG -
UNIFIED_AUDIT_TRAIL中字段SQL_TEXT含完整语句，OBJECT_SCHEMA/OBJECT_NAME可定位被授权对象，比标准审计的AUD$更直观
对象权限（如GRANT SELECT ON emp TO scott）为何审计不到
标准审计对对象权限的捕获是“按权限类型显式开启”的，AUDIT GRANT ANY PRIVILEGE只管系统权限，完全不管GRANT SELECT ON ...这种操作。
必须单独执行AUDIT GRANT ANY OBJECT PRIVILEGE，否则哪怕AUDIT_TRAIL=DB开着，这类语句也静默通过。
-
AUDIT GRANT ANY OBJECT PRIVILEGE捕获所有对象级授权（SELECT/INSERT/UPDATE/DELETE/EXECUTE等）和撤权 - 若用
AUDIT_TRAIL=DB,EXTENDED，SQL_TEXT字段会记录完整语句；若仅设DB，则只有操作类型和对象名，排查时缺上下文 - 注意：
GRANT ANY OBJECT PRIVILEGE本身是个系统权限，授予此权限的用户执行的GRANT才会被审计——普通用户直接授对象权限不触发此审计项
查不到审计记录时优先检查的三个硬性条件
别急着调参数或重装组件，先确认这三点是否全满足，90%的“审计没记录”问题出在这里。
-
SHOW PARAMETER audit_trail返回值必须是DB或DB,EXTENDED；NONE状态下所有AUDIT命令都无效 - 统一审计模式下，
SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing'必须返回TRUE；返回FALSE说明未relink，ALTER SYSTEM改AUDIT_TRAIL无意义 - 查
UNIFIED_AUDIT_TRAIL前，确保执行过GRANT READ ANY AUDIT RECORD TO your_user；否则权限不足，查出来永远空
最易忽略的是：多租户环境下，UNIFIED_AUDIT_TRAIL默认只查当前PDB，要跨容器审计得在CDB$ROOT中查，且CON_ID字段得参与过滤。
