ASH不适合诊断批量插入性能恶化，因其采样间隔长、内存缓冲小、无法捕获直接路径插入的短事务及日志等待根因，需依赖v$session_event、AWR报告和归档日志速率实时定位。
ASH 不适合诊断批量插入性能恶化——它大概率捕获不到关键过程，强行用只会误导根因判断。
为什么 v$active_session_history 查不到批量插入的瓶颈
批量插入（尤其是 INSERT /*+ APPEND */ 或 JDBC addBatch()）执行快、等待少、不走常规锁和 I/O 路径，ASH 每秒采样一次且只保留内存缓冲区（默认约 30MB），高负载下样本极易被覆盖。更关键的是：
- 直接路径插入不产生
db file sequential read等典型等待，ASH 里可能根本没记录 - 短事务（如每 1000 行
commit）在采样窗口中“一闪而过”，SAMPLE_TIME很难对齐到实际阻塞点 -
log file sync等日志类等待在 ASH 中只显示“有会话在等”，但无法关联到具体哪次commit、哪条 SQL 触发了刷日志风暴 -
dba_hist_active_sess_history是 AWR 压缩归档表，采样粒度降为 10 秒，且默认只保留 7–8 天，对刚发生的性能毛刺基本无效
该盯哪三个实时指标，而不是翻 ASH
真要定位批量插入恶化，立刻查以下三项，比等 ASH 出结果快 10 秒以上：
- 实时
v$session_event：重点关注log file sync和log file parallel write的TIME_WAITED是否突增，再结合COUNT(*)判断是否高频小提交 - AWR 报告的
Top 5 Timed Events+SQL Statistics：导入完成后立刻运行@?/rdbms/admin/awrrpt.sql，看log file sync占比是否超 30%，同时核对Redo size/s是否异常飙升 - 归档日志生成速率：
SELECT TO_CHAR(first_time,'HH24:MI') time, COUNT(*) cnt FROM v$log_history WHERE first_time > SYSDATE - 1/24 GROUP BY TO_CHAR(first_time,'HH24:MI') ORDER BY time；若某分钟归档量突增 5 倍，基本可断定是commit频次失控
如果非要从 ASH 查日志等待，必须加硬过滤条件
别直接 SELECT * FROM dba_hist_active_sess_history，那样全是噪音。有效查询必须满足：
- 时间范围精确到秒级：
SAMPLE_TIME BETWEEN TO_TIMESTAMP('2026-09-17 22:15:00','YYYY-MM-DD HH24:MI:SS') AND TO_TIMESTAMP('2026-09-17 22:15:30','YYYY-MM-DD HH24:MI:SS') - 限定事件类型：
event IN ('log file sync', 'log file parallel write') - 绑定会话来源：
sql_id IN (SELECT sql_id FROM v$sql WHERE sql_text LIKE '%INSERT%INTO%')，避免把归档进程或 LGWR 自身的等待混进来 - 排除空闲会话：
session_state = 'WAITING'且blocking_session IS NULL（日志等待通常不被阻塞，而是主动等待）
真正容易被忽略的点是：批量插入恶化往往不是 SQL 本身变慢，而是事务控制策略（如 commit 频次）、redo 日志写入压力、归档吞吐能力三者叠加失衡的结果。ASH 只能反映“谁在等”，但看不出“为什么等”——那得靠归档速率、redo/s、以及应用层 commit 逻辑交叉验证。
