如何借助Oracle ASH视图监控当前正在运行的长事务进度？

不能用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 只是辅助定位“它此刻是否活跃作恶”的放大镜，不是进度表盘。