不能用V$ACTIVE_SESSION_HISTORY直接监控长事务进度，因其仅采样活动会话瞬时状态，不反映事务内部回滚块处理、完成百分比或剩余时间；真正进度需查v$fast_start_transactions（崩溃恢复事务）或x$ktuxe（实时undo块速率）结合v$transaction定位。
不能用 v$active_session_history 直接监控长事务“进度”，它只记录活动会话的瞬时快照，不反映事务内部状态或剩余工作量。
为什么 ASH 查不到事务回滚或提交进度
ASH 的采样对象是「正在执行」的会话行为：CPU 运行、非空闲等待事件。而事务真正回滚时，由 SMON 并行驱动，不走用户会话 SQL 执行链，也不产生 SQL_ID；你看到的 enq: TX - row lock contention 或 wait for a undo record 只表示“被卡住”，不是“正在回滚”。V$ACTIVE_SESSION_HISTORY 里查不到回滚块处理数量、已完成百分比、预计耗时等关键指标。
该查什么视图才能知道长事务真实进度
必须绕开 ASH，直查 Oracle 恢复子系统内部视图：
-
v$fast_start_transactions：只对崩溃恢复或实例重启后触发的快速启动恢复有效，提供undoblocksdone和undoblockstotal，可算出完成百分比 -
x$ktuxe：底层事务条目，ktuxesiz是当前活跃 undo 块数；连续两次查询差值除以时间间隔，就是实时回滚速率（单位：undo 块/秒） -
v$transaction+v$session：用于反向定位发起者——通过taddr关联saddr，拿到原始SID、USERNAME、PROGRAM
注意：v$fast_start_transactions 不包含正常会话中手动 ROLLBACK 的事务；这类事务必须结合 x$ktuxe 和 v$transaction 查。
如何关联 ASH 辅助判断长事务是否正在造成阻塞
ASH 不管进度，但能告诉你这个事务“现在有没有在惹事”：
- 查
V$ACTIVE_SESSION_HISTORY时加WHERE sample_time > SYSDATE - 1/1440（过去 1 分钟），避免噪声 - 重点看
session_id、blocking_session、final_blocking_session三字段组合，暴露级联阻塞链 - 若同一
session_id连续多条记录显示event = 'enq: TX - row lock contention'或'library cache lock'，说明它正持锁并引发连锁影响 - 再用该
session_id去查V$SESSION和V$TRANSACTION，确认是否真有未提交事务、used_ublk是否持续增长
MODULE 和 ACTION 字段在这里容易误导
应用层设置的 MODULE（如 'ORDER-SERVICE'）可用于快速圈定可疑会话范围，但要注意：
-
ACTION在事务提交/回滚后常为空或残留旧值，不能作为“当前动作”依据 - 大量样本中
ACTION IS NULL很常见，不代表没设，可能只是应用没调用DBMS_APPLICATION_INFO.SET_ACTION - 不要在
DBA_HIST_ACTIVE_SESS_HISTORY上依赖ACTION过滤——AWR 快照每小时一次，ACTION值大概率已丢失
真正要盯住长事务影响，得靠 V$SESSION.STATUS、V$TRANSACTION.START_DATE、V$SESSION.LAST_CALL_ET 和 LOGON_TIME 交叉验证连接与事务生命周期，ASH 只是辅助定位“它此刻是否活跃作恶”的放大镜，不是进度表盘。
