ash查不到truncate执行记录是正常的，因其为瞬时ddl操作，不进入sql执行引擎路径，ash仅采样“等待”或“cpu运行”状态；真正可观测的是其引发的enq: tm/ddl - contention锁等待事件，通过blocking_session可定位阻塞源头。
ASH里查不到TRUNCATE的执行记录，这是正常的
因为TRUNCATE是DDL操作，Oracle默认不将其完整记录在V$ACTIVE_SESSION_HISTORY（ASH）中——它只捕获会话在“等待”或“CPU运行”状态下的采样快照，而TRUNCATE本身执行极快（通常毫秒级），且不走SQL执行引擎路径，ASH采样几乎无法捕捉到其活跃帧。你翻遍ASH找不到TRUNCATE TABLE语句，不是查询姿势问题，是机制限制。
真正要盯的是TRUNCATE引发的锁等待链
TRUNCATE需要获取TM（表级）排他锁，且在高版本Oracle（12c+）中还会隐式请求DDL锁（Exclusive DDL lock）。如果此时有长事务正持有该表的TM锁（比如未提交的INSERT/UPDATE/DELETE），或另一个会话正在对该表做ALTER、DROP等DDL，TRUNCATE就会卡在enq: TM - contention或enq: DDL - contention等待上。这时ASH才真正有用：
- 查
ASH中等待事件为enq: TM - contention或enq: DDL - contention的会话，用SESSION_ID和SQL_ID定位阻塞源头 - 通过
BLOCKING_SESSION和BLOCKING_SESSION_SERIAL#反向追踪谁在持锁 - 结合
DBA_BLOCKERS和DBA_WAITERS交叉验证（注意：这两个视图只反映当前瞬态，ASH可回溯过去30分钟，默认保留）
用ASH定位阻塞源头的实操SQL
以下SQL适用于排查最近15分钟内因TRUNCATE被阻塞的会话（需有SELECT_CATALOG_ROLE或SELECT ANY DICTIONARY权限）：
SELECT
SAMPLE_TIME,
SESSION_ID,
SESSION_SERIAL#,
SQL_ID,
EVENT,
BLOCKING_SESSION,
BLOCKING_SESSION_SERIAL#,
CURRENT_OBJ#,
OBJECT_NAME
FROM V$ACTIVE_SESSION_HISTORY a
JOIN DBA_OBJECTS o ON a.CURRENT_OBJ# = o.OBJECT_ID
WHERE a.EVENT IN ('enq: TM - contention', 'enq: DDL - contention')
AND o.OBJECT_NAME = 'YOUR_TABLE_NAME' -- 替换为实际表名
AND SAMPLE_TIME > SYSDATE - 15/(24*60)
ORDER BY SAMPLE_TIME DESC;
关键点：
-
CURRENT_OBJ#必须关联DBA_OBJECTS才能确认是否真指向目标表（仅靠SQL_TEXT不可靠，因为TRUNCATE的SQL_ID在ASH中常为空或为NULL） - 若
BLOCKING_SESSION非空，查该会话的V$SESSION.SQL_ID和PREV_SQL_ID，再查V$SQL.SQL_TEXT看它在执行什么（很可能是未提交DML或另一条DDL） - 注意
EVENT中的锁模式：TM锁的mode#值可通过V$LOCK_TYPE查，mode=6代表Exclusive，说明对方已加了排他锁
容易被忽略的陷阱：TRUNCATE + RECYCLEBIN 和分区表
两个隐蔽但高频的阻塞场景：
- 当
RECYCLEBIN开启（默认ON），TRUNCATE虽不进回收站，但若表上有依赖物（如物化视图日志、XMLIndex），Oracle可能在内部尝试清理元数据，触发短暂DDL锁争用——此时ASH中等待事件仍为enq: DDL - contention，但CURRENT_OBJ#可能指向系统对象而非你的表 - 对分区表执行
TRUNCATE TABLE ... DROP STORAGE时，若启用了INMEMORY，Oracle需同步刷新in-memory area，可能卡在inmemory populate等待上，这个不会体现为TM锁，而是latch: inmemory journal latch类事件，需单独筛查
这类情况的共性是：ASH里能看到等待，但BLOCKING_SESSION为空或指向后台进程（如ora_q000_*），说明阻塞来自Oracle自身维护动作，而非用户会话——这时候得结合V$SESSION_LONGOPS和AWR报告进一步下钻。
