查ash中持续生成undo的会话需重点关注event和session_state：长期等待enq: us - contention、undo segment extension或db file sequential read且session_state为waiting，表明事务卡在回滚段争用或空间分配环节；再联查v$transaction识别未提交的“挂尸”事务（used_ublk>10000、used_urec/used_ublk>50），并结合dba_hist_active_sess_history回溯历史峰值及v$undostat验证真实undo压力。
查ash里谁在持续生成undo：别只看sql_id，重点盯event和session_state
ash（active session history）本身不直接记录undo块消耗量，但它能暴露长事务的典型行为模式：会话长时间卡在enq: us - contention、undo segment extension或db file sequential read（读回滚段头块）上，且session_state长期为waiting而非on cpu。这不是“慢sql”，而是事务卡在空间分配或回滚段争用环节。
- 执行
SELECT sample_time, session_id, sql_id, event, session_state, p1text, p1, p2text, p2 FROM v$active_session_history WHERE event IN ('enq: US - contention', 'undo segment extension', 'db file sequential read') AND sample_time > SYSDATE - 1/24 ORDER BY sample_time DESC，查最近1小时的高频等待 - 若
event = 'enq: US - contention'且p1 = 1415053317（US enqueue的type#），说明多个会话在抢同一个回滚段头；若p2值反复出现相同数字，大概率是某几个回滚段被反复争抢 -
SESSION_STATE = 'WAITING'且event持续超过5分钟，基本可判定该会话已陷入长事务阻塞链，不是临时抖动
关联V$TRANSACTION定位真实事务起点：START_TIME ≠ 实际活跃时间
ASH里看到的会话可能只是“受害者”，真正吃Undo的是那个没提交的源头事务。V$TRANSACTION的START_TIME容易误导——它只反映事务第一次DML的时间，但一个空闲连接挂着未提交（比如应用层连接池没设超时），START_TIME可能几小时之前，而ASH里看不到它的活动痕迹。
- 必须联查：
SELECT s.sid, s.serial#, s.username, s.status, s.sql_id, t.start_time, t.used_ublk, t.used_urec FROM v$session s JOIN v$transaction t ON s.saddr = t.ses_addr WHERE t.start_time - 重点关注
status = 'INACTIVE'但used_ublk > 10000的会话——这是典型的“挂尸”事务，占着Undo不放，却不在ASH里刷存在感 -
used_urec远大于used_ublk（比如比值＞50），说明事务修改了大量行但未提交，Undo碎片化严重，回收效率低
用DBA_HIST_ACTIVE_SESS_HISTORY回溯历史峰值：ASH默认只保留1小时，得挖AWR快照
生产环境出问题往往不是实时发生的，而是某个夜间批处理或凌晨报表作业留下的“后遗症”。ASH内存视图刷掉后，只能靠AWR里的历史ASH数据（DBA_HIST_ACTIVE_SESS_HISTORY）还原现场。
- 查故障时段的快照ID：
SELECT snap_id, begin_interval_time FROM dba_hist_snapshot WHERE begin_interval_time BETWEEN TO_DATE('2026-06-17 02:00', 'YYYY-MM-DD HH24:MI') AND TO_DATE('2026-06-17 04:00', 'YYYY-MM-DD HH24:MI') - 查该时段Undo争用最集中的会话：
SELECT session_id, session_serial#, sql_id, COUNT(*) cnt FROM dba_hist_active_sess_history WHERE snap_id IN (xxx, yyy) AND event IN ('enq: US - contention', 'undo segment extension') GROUP BY session_id, session_serial#, sql_id ORDER BY cnt DESC - 注意：Oracle 11g中
DBA_HIST_ACTIVE_SESS_HISTORY默认每10分钟采样一次，分辨率不如实时ASH，但足够定位到小时级的问题窗口
结合V$UNDOSTAT确认Undo压力是否匹配：ASH异常≠Undo真爆了
ASH看到大量US争用，未必代表Undo表空间已满——可能只是瞬时高峰被采样到了。必须交叉验证V$UNDOSTAT里的硬指标，否则容易误判。
- 执行
SELECT begin_time, end_time, undoblks, txncount, maxconcurrency, unxpstealcnt FROM v$undostat WHERE begin_time > SYSDATE - 1/24 ORDER BY begin_time DESC - 如果
maxconcurrency ≥ 20且连续多个快照出现，同时unxpstealcnt > 0（表示被迫覆盖未过期Undo），再叠加ASH里对应时段的US争用，才能确认是真实Undo压力 -
undoblks突增但txncount平稳，说明单个事务Undo消耗暴增（比如大范围DELETE）；反之txncount翻倍而undoblks只微涨，可能是小事务并发激增，争用回滚段头
真实难点不在查，而在确认“哪个事务该杀、哪个该等”。很多长事务背后是业务强一致性要求（比如金融核保），贸然KILL会引发下游补偿逻辑失败。所以ASH分析完，一定得拉应用方一起看sql_id对应的业务上下文，而不是只盯着数据库参数调。
