统一审计启用后dba_priv_audit_opts不再记录操作详情，仅存权限审计开关状态；所有实际操作记录均写入unified_audit_trail，须据此查询时间、用户、sql等完整信息。
统一审计不是开关一按就完事，它必须停库重链才能生效，且启用后 dba_priv_audit_opts 就不再反映策略——真要查谁干了什么，得盯紧 unified_audit_trail。
为什么 DBA_PRIV_AUDIT_OPTS 查不到实际操作记录
这个视图只存「哪些权限审计被打开过」，比如 GRANT ANY PRIVILEGE 是否设为 BY ACCESS，但它不记录时间、用户、SQL 或 IP。你翻它一百遍，也看不到某人昨天用 ALTER SYSTEM 关了密码复杂度校验——那条记录在 UNIFIED_AUDIT_TRAIL 里。
- 如果数据库是 12c+ 且已启用统一审计，
DBA_PRIV_AUDIT_OPTS往往为空，所有策略都走UNIFIED_AUDIT_POLICIES - 传统审计的
DBA_AUDIT_TRAIL在统一审计启用后仍可能有残留，但新行为默认不写入 - 误以为开了
AUDIT GRANT ANY PRIVILEGE就能捕获所有提权动作，其实它只抓显式GRANT语句，PL/SQL 包内调用或 JOB 触发的不会出现
启用统一审计必须停库重链，不能在线改
Oracle 的统一审计不是参数改完 ALTER SYSTEM 就生效的机制。它依赖底层链接时嵌入的审计模块，所以必须完整走一遍停库 → 停监听 → 重链 uniaud_on → 启库流程。
- 停库前确认有
AUDIT_SYSTEM或AUDIT_ADMIN权限，否则shutdown immediate都可能失败 - 重链命令是
make -f ins_rdbms.mk uniaud_on ioracle，路径必须在$ORACLE_HOME/rdbms/lib下执行 - 启库后立刻验证：
SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing'必须返回TRUE，否则后续所有策略都不生效
查高危操作必须过滤 UNIFIED_AUDIT_TRAIL 的关键字段
真正监控 ALTER SYSTEM、GRANT ANY ROLE、DROP USER 这类行为，得直接查 UNIFIED_AUDIT_TRAIL，并组合多个字段交叉判断。
- 用
ACTION_NAME IN ('ALTER SYSTEM', 'GRANT', 'DROP USER')做主过滤，别只靠SQL_TEXT模糊匹配 - 加
CLIENT_PROGRAM_NAME识别是否来自sqlplus、jdbc thin或中间件（如WebLogic） - 看
PROXY_SESSIONID和OS_USERNAME，区分真实操作者和连接池代理身份 - 注意
RETURN_CODE != 0的记录：多次ALTER SYSTEM SET ... SCOPE=SPFILE失败，很可能是试探性越权
AUDIT_TRAIL=DB,EXTENDED 对统一审计无效，别混用
传统审计的 DB,EXTENDED 是为了让 DBA_AUDIT_TRAIL 包含 SQL_TEXT，但它和统一审计互斥。一旦启用统一审计，AUDIT_TRAIL 参数就退化为兼容性占位符，再设成 DB,EXTENDED 不影响 UNIFIED_AUDIT_TRAIL 的内容，但会误导人去查错表。
- 统一审计下，
SQL_TEXT字段在UNIFIED_AUDIT_TRAIL中天然可用，无需额外配置 -
AUDIT_SYS_OPERATIONS=TRUE在统一审计启用后自动失效，SYS 操作由ORA_SECURECONFIG等预定义策略覆盖 - 最常漏掉的是时间范围：查
UNIFIED_AUDIT_TRAIL一定要加EVENT_TIMESTAMP > SYSDATE - 1/24，否则全表扫描极慢
统一审计启用后，真正的难点不在开启动作本身，而在于策略粒度控制和日志解读——比如一个 GRANT SELECT ANY DICTIONARY TO hr_app 可能是运维脚本执行，也可能是攻击者植入，得结合 SESSIONID、OS_PROCESS 和前后几秒的其他审计事件一起看，单条记录几乎无法定性。
