ash查不到delete慢的直接证据，因为delete前台执行快，真正耗时的是后台m00进程同步写mlog$_表、维护索引、刷redo等动作；应通过program like '%m00%'、session_state='waiting'及特定等待事件定位日志写入瓶颈。
为什么ash查不到delete慢的直接证据
物化视图日志导致的delete慢，ash里往往看不到delete语句本身在等待——因为delete前台执行快，真正耗时的是后台同步写mlog$_表、维护索引、刷redo这些动作，它们分散在ora_lgwr_*、ora_dbw0_*等后台进程里，ash默认只采样前台会话。你搜delete语句的sql_id，大概率返回空或只有零星样本。
该盯哪些ASH字段组合定位日志写入瓶颈
别找DELETE，要找触发它的后台递归路径。关键过滤条件是：
-
program LIKE '%M00%'或program LIKE '%oracle@%M%'：物化视图刷新和日志写入由M00后台进程驱动 -
session_state = 'WAITING'：排除ON CPU干扰，专注真实阻塞点 -
event IN ('log file sync', 'enq: TX - row lock contention', 'db file sequential read')：这三类事件最常暴露日志表IO或锁问题 -
current_obj#关联dba_objects查是否指向MLOG$_xxx表：确认等待对象确实是物化视图日志表
结合v$session_event比ASH更准
ASH对短时高吞吐DML采样易丢失，v$session_event能抓到实时累积等待。立刻执行：
SELECT sid, event, p1text, p1, p2text, p2, seconds_in_wait
FROM v$session_event
WHERE event IN ('log file sync', 'enq: TX - row lock contention', 'db file sequential read')
AND sid IN (SELECT sid FROM v$session WHERE sql_id IN (
SELECT sql_id FROM v$sql WHERE sql_text LIKE '%DELETE%FROM YOUR_TABLE%'));
如果log file sync等待时间高，说明MLOG$_表所在表空间IO跟不上；如果enq: TX持续存在，检查p1解出对象ID，再查是否是MLOG$_xxx被其他会话持锁。
容易忽略的物化视图日志配置陷阱
很多DELETE慢根本不是SQL写得差，而是日志表自身设计拖后腿：
-
MLOG$_xxx表没挪到LOCAL+AUTOALLOCATE专用SSD表空间，还在USERS或SYSTEM里混着——IO争用直接拉高log file sync - 手动多建了
ON (seq$$)或ON (snaptime$$, dmltype$$)索引，每次DELETE都要多维护一个索引块 - 启用了
ROW MOVEMENT或COMPRESS FOR OLTP，实测单条日志插入从0.2ms升到1.5ms+
真正卡点往往不在DELETE语句本身，而在MLOG$_表的物理存放位置、索引数量和表属性——这些不改，光调SQL没用。
