oracle审计本身不写入v$active_session_history，但会引发log file sync、enq: ts/us contention、cursor: pin s wait on x等等待事件，并通过program/action/client_id组合在ash中暴露审计负载痕迹，需结合采样密度与等待时间变化交叉验证。
oracle 的审计功能本身不会直接写入 v$active_session_history，但开启细粒度审计（尤其是 unified_audit_trail 或传统 aud$ 写入频繁）会导致大量后台会话争用、日志刷写和 i/o 延迟，这些行为会在 ash 中留下清晰痕迹——关键不是找“audit”关键字，而是识别由审计引发的等待链和会话模式。
查 V$ACTIVE_SESSION_HISTORY 里高频出现的审计相关等待事件
审计密集型负载下，ASH 最常暴露两类等待：一是写审计记录时的同步 I/O 等待，二是审计日志缓冲区争用。重点关注以下事件：
-
log file sync出现频次异常高（尤其伴随高log file parallel write），说明每次 COMMIT 都在等审计日志落盘 —— 这是UNIFIED_AUDIT_TRAIL启用BY ACCESS且未关闭IMMEDIATE刷写时的典型表现 -
enq: TS – contention或enq: US – contention高频出现，指向审计表空间（如AUDIT_TS）或UNIFIED_AUDIT_TRAIL所在表空间的段头/位图争用 -
cursor: pin S wait on X在多个会话中同时出现，且sql_id聚集在INSERT INTO unified_audit_trail或INSERT INTO aud$类似语句上，说明审计写入路径被串行化阻塞
过滤出审计模块触发的活动会话样本
Oracle 不会把“审计操作”单独标记为模块名，但可通过 program、action 和 client_id 组合缩小范围。执行如下查询可快速定位可疑样本：
SELECT sample_time, session_id, sql_id, event, program, action, client_id
FROM v$active_session_history
WHERE sample_time > SYSDATE - 1/24
AND (program LIKE '%ora_audit%'
OR action IN ('LOGON', 'LOGOFF', 'AUDIT')
OR client_id LIKE 'AUD%')
ORDER BY sample_time DESC;
注意：client_id 字段若被应用显式设置为 AUDIT_JOB 或类似值，是极强信号；而 program 显示 ora_p000_* 且 action 为 AUDIT，大概率是后台审计归档进程（ora_cjq0 或 ora_m000）在刷盘卡住。
对比启用/禁用审计前后的 ASH 样本密度变化
ASH 的采样频率（默认 1 秒）对瞬时审计风暴很敏感。若怀疑审计是瓶颈，不要只看单次报告，要横向比对：
- 启用审计前后 5 分钟内，
COUNT(*)从v$active_session_history中提取的样本数是否突增 3 倍以上？突增说明大量会话卡在审计路径 - 检查
session_state字段：启用审计后，WAITING样本占比是否从 60% 升至 90%+，且ON CPU样本锐减？这表示 CPU 并未打满，但会话被审计 I/O 强制挂起 - 对比
time_waited：同一sql_id在审计开启后，其关联的log file sync累计等待时间是否增长 10 倍？如果是，基本锁定审计日志刷写策略不当
为什么直接查 DBA_AUDIT_TRAIL 或 UNIFIED_AUDIT_TRAIL 没用？
因为性能瓶颈从来不在审计记录“存没存进去”，而在“怎么存进去”。DBA_AUDIT_TRAIL 是结果视图，延迟高、不可实时反映争用；而 UNIFIED_AUDIT_TRAIL 默认基于外部表实现，查询它本身就会加重负担。ASH 的价值恰恰在于它不依赖审计表内容，而是捕获会话在写入审计前那一毫秒的真实状态——比如一个会话正持有 library cache lock 等待审计触发器编译完成，这种链路只有 ASH 能断点抓取。
