必须查gv$active_session_history而非v$transaction，因后者在RAC下常存已提交的“幽灵记录”，而ASH每秒采样可实时识别长期WAITING、反复锁等待的活跃会话；须用gv$前缀、限定最近5分钟、关注final_blocking_session/instance及p1raw值区分真/假行锁。
查 gv$active_session_history 而不是 v$transaction
只查 v$transaction 会误判：它只存事务起始时间、回滚段用量等静态字段，且 RAC 环境下常残留已提交事务的“幽灵记录”。真正反映长事务是否正在造成影响的，是 gv$active_session_history——它每秒采样一次，能连续看到同一 session_id 是否长期处于 WAITING 状态、是否反复触发锁等待或空挂。
必须用 gv$ 前缀：微服务或批处理常跨 RAC 实例运行，v$ 视图只返回当前实例数据，90% 的持锁者会漏掉。
- 时间过滤强制设为
SAMPLE_TIME > SYSDATE - 5/1440（最近 5 分钟），避免扫全缓冲区导致查询卡死或权限报错ORA-00942 - 关键字段必须同时查：
session_id、blocking_session、final_blocking_session、final_blocking_instance - 若
final_blocking_session为空或为 0，且该会话event是SQL*Net message from client，大概率就是那个没发COMMIT的根因会话
识别“真行锁”还是“假行锁”
看到 enq: TX - row lock contention 不能直接 kill。先查该会话的 p1raw 值：
-
p1raw = '54580006'→ mode=6 → 真正的行级锁冲突，A 更新某行未提交，B 死等同一行 -
p1raw = '54580004'→ mode=4 → 很可能不是行锁，而是唯一键冲突或 ITL 不足，杀掉等待者无用，下一个会话照样报ORA-00001或继续等
验证是否唯一键冲突：看对应 sql_id 的语句是不是 INSERT INTO ... VALUES (...)，且 CURRENT_OBJ# 指向唯一索引所在表。
定位长事务的 SQL 执行进度
ASH 不记录事务内每条语句的执行顺序，但可通过高频重复的 sql_id + current_obj# 组合反推进度：
- 同一
sql_id在 5 分钟内出现 >20 次样本，基本锁定是主执行 SQL -
CURRENT_OBJ#高度集中（如连续多行都是 12345），说明事务正密集操作某张核心表，可能是批处理的目标表 - 若
event从db file sequential read切换到enq: TX%，说明已读完数据开始更新，进入锁争用阶段 - 若长时间卡在
SQL*Net message from client，且time_waited持续增长，说明应用端没推进，事务空挂
别忽略 MMNL 进程异常导致的 ASH 数据丢失
ASH 缓冲区默认保留约 1 小时，靠 MMNL 进程把内存数据刷到磁盘。如果这个进程被阻塞或异常终止，你查到的 gv$active_session_history 就是“断层”的——看起来事务突然消失，其实只是采样中断了。
检查方式：
- 查
v$process中name = 'MMNL'的进程是否存在且状态正常 - 对比
v$active_session_history最大SAMPLE_TIME和当前时间，若差值 >2 分钟，要怀疑 MMNL 是否失联 - 此时不能仅依赖 ASH，需立即补抓
System State Dump（oradebug dump systemstate 266）和gv$transaction快照
最易被忽略的是：当事务本身没卡住，但 MMNL 卡了，你会误以为“没发生长事务”，实际只是监控失效了。
