ash不能实时监控批量导入过程，因其每秒采样且缓冲区易覆盖，短事务和直接路径插入常未被捕获，归档表dba_hist_active_sess_history更滞后且粒度粗。
ash 不是用来“监控实时负载变化”的工具，它本质是采样快照，滞后且有损。批量导入性能问题若靠 v$active_session_history 或 dba_hist_active_sess_history 去“盯”过程，大概率错过关键窗口或误判根因。
为什么不能用 ASH 实时看批量导入过程
ASH 每秒采样一次活动会话，但只保留 SGA 中的循环缓冲区（默认最多 30MB），实际保存时长取决于数据库活跃度。高并发批量导入期间，MMNL 进程可能来不及写满缓冲区就被覆盖；而导入语句本身若执行快、等待少，很可能根本不出现在采样中——尤其当它跑在 SQL*Plus 或应用连接里、不显式等待 I/O 或锁时。
- ASH 不记录空闲会话，也不记录已完成的短事务，
INSERT /*+ APPEND */类直接路径插入常无显著等待事件 -
dba_hist_active_sess_history是 AWR 快照压缩后的归档表，采样粒度降为每 10 秒一次，且默认只保留 7–8 天，无法回溯到导入刚发生时的精确秒级行为 - 导入过程中若出现日志等待（如
log file sync、log file parallel write），ASH 只能告诉你“有会话在等”，但无法区分是 DML 触发的提交刷日志，还是归档进程卡住，更无法关联到具体 INSERT 语句的 commit 频次
该用什么替代 ASH 来定位批量导入瓶颈
真要抓批量导入的性能毛刺，优先看三个地方：实时 v$session_event、AWR 报告的 Top 5 Timed Events + SQL Statistics，以及归档日志生成速率。ASH 只适合事后辅助验证。
- 导入开始前，运行
SELECT sid, event, p1text, p1, p2text, p2, seconds_in_wait FROM v$session_event WHERE event IN ('log file sync', 'log file parallel write', 'db file sequential read') AND sid IN (SELECT sid FROM v$session WHERE program LIKE '%sqlplus%' OR module LIKE '%batch%');—— 这比等 ASH 出报告快 10 秒以上 - 导入完成后立刻拉 AWR 报告（
@?/rdbms/admin/awrrpt.sql），重点看 “Load Profile” 里的 “Redo size/s” 和 “Logons/sec”，再对照 “Top 5 Timed Events” 是否出现log file sync占比超 30% - 查归档压力：
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 倍，基本可断定是批量提交太频繁
如果非要从 ASH 查日志等待，得这么筛
别直接 SELECT * FROM dba_hist_active_sess_history，那样数据量大、字段多、时间难对齐。必须加强过滤条件，否则查出来全是噪音。
- 限定时间范围：用
SAMPLE_TIME BETWEEN TO_TIMESTAMP('2026-04-30 07:20:00','YYYY-MM-DD HH24:MI:SS') AND TO_TIMESTAMP('2026-04-30 07:25:00','YYYY-MM-DD HH24:MI:SS')，误差控制在 ±30 秒内 - 聚焦关键事件：
WHERE event IN ('log file sync', 'log file parallel write', 'enq: TX - row lock contention')，排除所有空闲和网络类等待 - 关联 SQL：
AND sql_id IS NOT NULL，再 JOINdba_hist_sqltext看实际语句；注意sql_id在 ASH 中可能为空，因为绑定变量未解析完成 - 聚合看趋势：
SELECT TRUNC(sample_time,'MI') minute, event, COUNT(*) cnt FROM dba_hist_active_sess_history WHERE ... GROUP BY TRUNC(sample_time,'MI'), event ORDER BY minute;—— 这才能看出每分钟日志等待是否随导入节奏脉冲式上升
真正卡住批量导入的，往往是 COMMIT 频次、归档目标 IO 吞吐、或者 LOG_BUFFER 大小不够撑住峰值 redo。ASH 提供的是“谁在等”的快照，不是“为什么等”的因果链。想准确定位，得把 AWR 的宏观指标、实时动态视图的瞬时状态、和 OS 层的磁盘延迟（iostat -x 1）三者交叉印证，而不是依赖单一采样源。
