不应使用ddl/dml触发器作为审计主干，因其无法捕获直接路径加载、并行dml等操作，触发器失败会破坏事务，高并发下性能差，且无法记录绑定变量、执行计划、客户端ip等关键信息。
oracle数据库本身不支持“多级审计”这个官方概念，但用户常把“标准审计 + 细粒度审计 + 自定义触发器记录”组合称为多级——这种做法实际增加了管理复杂度和性能风险，不推荐在生产环境用触发器补全dml审计。
为什么不该用DDL/DML触发器做审计主干
触发器记录DML（如INSERT/UPDATE/DELETE）看似灵活，但存在几个硬伤：
- 无法捕获直接路径加载（
INSERT /*+ APPEND */）、并行DML、物化视图刷新等绕过触发器的操作 - 触发器自身执行失败会导致业务SQL报错（比如日志表空间满、权限不足），破坏事务原子性
- 高并发下容易成为性能瓶颈，尤其是
AFTER EACH ROW触发器写入审计表时产生大量redo和锁争用 - 无法记录绑定变量值、执行计划、客户端IP、程序名等关键上下文，而统一审计（
UNIFIED_AUDIT_TRAIL）原生支持这些字段
真正该用的替代方案：统一审计策略 + FGA
Oracle 12c 及以后版本（含19c/21c）应优先使用统一审计框架，它天然支持分层审计逻辑：
- 基础层：审计所有
SELECT/UPDATE/DELETEon 敏感表，用CREATE AUDIT POLICY定义，例如：CREATE AUDIT POLICY hr_emp_dml_policy ACTIONS SELECT, INSERT, UPDATE, DELETE ON hr.employees;
- 增强层：对工资列等敏感字段加细粒度审计（FGA），只在满足条件时触发，避免全表扫描开销：
BEGIN DBMS_FGA.ADD_POLICY( object_schema => 'HR', object_name => 'EMPLOYEES', policy_name => 'salary_access_audit', audit_condition => 'SALARY > 10000', audit_column => 'SALARY' ); END;
- 系统层：启用
AUDIT_SYS_OPERATIONS=TRUE，确保SYSDBA操作也被捕获到UNIFIED_AUDIT_TRAIL中，而非仅靠OS文件
如果真要临时用触发器，必须绕开哪些坑
仅限测试或极短期应急，且必须满足以下条件：
- 触发器类型必须是
AFTER STATEMENT，而非AFTER EACH ROW，否则性能雪崩 - 审计日志表（如
audit_log_dml）需单独放在高性能SSD表空间，且禁用logging（NOLOGGING）减少redo压力 - 触发器内必须用
PRAGMA AUTONOMOUS_TRANSACTION提交日志，否则会受主事务回滚影响导致审计丢失 - 必须显式捕获
ORA_LOGIN_USER、SYS_CONTEXT('USERENV','IP_ADDRESS')、SYSTIMESTAMP，不能依赖USER或SYSDATE
最易被忽略的一点：统一审计策略默认不记录SQL文本中的字面量（literal），需额外设置AUDIT_UNIFIED_ENABLED_POLICIES并确认UNIFIED_AUDIT_TRAIL视图中SQL_TEXT列非空；而触发器永远拿不到绑定变量值，这点在溯源SQL注入或越权访问时直接失效。
