ON COMMIT刷新拖慢DML的根本原因是每次提交强制触发增量更新，使轻量事务陷入重锁链，受MLOG和MV表行锁阻塞，导致enq: TX等待。
ON COMMIT刷新为什么会让业务DML变慢甚至卡住
根本原因不是“刷新慢”，而是每次基表提交都强制触发一次物化视图增量更新，把原本轻量的事务拖进一个更重的锁链里。这个过程会读取物化视图日志（MLOG$_xxx），再对物化视图表做DML，全程受事务一致性约束——只要日志表或MV表上有行被其他会话锁住，当前提交就会等在enq: TX - row lock contention上。
常见现象包括：INSERT/UPDATE响应时间从几毫秒跳到数百毫秒；批量导入时大量会话堆积在enq: TX；v$session里看到blocking_session指向一个看似无关的J000后台进程（其实是MV刷新作业）。
- ON COMMIT要求基表必须有主键或唯一约束，否则建MV直接报
ORA-12052 - 物化视图日志必须含
ROWID和所有SELECT列，缺一不可；否则刷新时查不到变更记录，退化为全量扫描 - 哪怕MV只含单表、无聚合，一旦基表并发写入高，MLOG$_xxx上的
snaptime$$和sequence$$字段没索引，就会全表扫描+磁盘排序，拖慢整个提交链路
为什么v$locked_object里看不到ON COMMIT的锁持有者
因为ON COMMIT刷新由提交动作隐式触发，不走DBMS_MVIEW.REFRESH调用栈，锁由Oracle内部会话（如J000）在事务提交瞬间加，且生命周期极短——往往刚加完就释放。所以你查v$locked_object时大概率为空，但v$session里能看到大量会话卡在enq: TX或library cache lock上。
真正持锁的是那个正在提交的业务会话本身，不是独立的刷新进程。它一边要完成自己的INSERT/UPDATE，一边要顺带执行MV增量逻辑，两个动作共享同一事务上下文和锁资源。
- 查不到锁源？试试
SELECT sid, sql_id, event, blocking_session FROM v$session WHERE event LIKE 'enq: TX%'，重点关注blocking_session非空的行 - 确认是否真由ON COMMIT引发：临时禁用
ALTER MATERIALIZED VIEW mv_name DISABLE ON COMMIT REFRESH，观察业务DML是否恢复 - 别依赖
dba_mviews.refresh_mode = 'ON COMMIT'就认定生效——得查user_mview_logs里对应日志是否存在且状态正常
ON COMMIT刷新失败时错误藏得最深
它不会抛出明确错误，而是静默跳过本次刷新，物化视图状态变成STALE或UNUSABLE，后续查询可能返回旧数据甚至报ORA-01403。更麻烦的是，失败原因不会记进alert.log，也不会出现在DBA_JOBS_RUNNING里——因为它压根没起JOB。
真实错误只存在于10046 trace里，而且必须在问题发生前就打开。等用户反馈“数据不对”再回头追，基本找不到源头。
- 上线ON COMMIT MV前，务必先跑
DBMS_MVIEW.EXPLAIN_MVIEW('mv_name')，确认capable_name = 'FAST_REFRESH_ON_COMMIT'且possible = 'Y' - 定期检查
SELECT mview_name, staleness, status FROM dba_mviews，发现STALE立刻查v$session_longops找最近一次失败的刷新操作 - 避免在分区表上用ON COMMIT：TRUNCATE PARTITION后，日志SCN不推进，后续任何ON COMMIT刷新都会失效且不报错
替代方案比硬扛ON COMMIT更可控
绝大多数所谓“强一致”需求，其实容忍秒级延迟。用DBMS_SCHEDULER每30秒调一次DBMS_MVIEW.REFRESH('mv_name', method => 'F', atomic_refresh => FALSE)，配合fast_refreshable = 'FAST'验证，效果更稳、监控更明、出问题也更容易定位。
ON COMMIT是把一致性成本摊到每个写请求上，而定时FAST刷新是把它集中到后台——后者资源可调度、失败可重试、锁影响可预估。
- 定时刷新必须显式传
atomic_refresh => FALSE，否则默认TRUE会走DELETE+INSERT，undo暴涨、锁表时间线性增长 - 如果基表日志积压严重（
SELECT COUNT(*) FROM MLOG$_xxx WHERE snaptime$$ < SYSDATE - 1结果很大），先EXEC DBMS_MVIEW.PURGE_LOG('table_name', 1) - 别信
method => '?'（FORCE）：它会掩盖FAST失败的真实原因，比如日志被截断、查询含TRUNC(SYSDATE)，你只会看到“刷新完成了”，但数据早已停更
真正难处理的从来不是锁本身，而是ON COMMIT把锁的来源、持续时间和失败信号全部藏进了事务提交的原子性里——你看不见它，但处处被它拖慢。
