物化视图刷新锁表主因是atomic_refresh=TRUE导致事务级锁；应设为FALSE启用TRUNCATE+APPEND，验证FAST可刷性，禁用ON COMMIT，优化MLOG$_xxx索引与统计信息。
物化视图刷新时基表被锁，是因为 atomic_refresh 默认为 TRUE
oracle 11g 中 dbms_mview.refresh 默认启用 atomic_refresh => true，这会让刷新全程包裹在一个事务里：先 delete 旧数据，再 insert 新数据。这个过程必须保证一致性读（consistent read），因此会对基表上涉及的行加 tx 锁，甚至在某些场景下触发 tm 表级锁（如 truncate 被误用、或日志缺失导致退化为 complete）。业务 dml 正好修改同一行时，就会卡在 enq: tx - row lock contention。
常见错误现象包括：
-
SELECT * FROM v$locked_object显示基表（如SALES）被锁，locked_mode为 3（ROW EXCLUSIVE）或 6（EXCLUSIVE） - 应用报
ORA-00054: resource busy and acquire with NOWAIT specified - 刷新耗时远超预期，且
v$session.event长期停留在db file sequential read或enq: TX
解决方法不是调优 SQL，而是改刷新语义：
- 显式传参
atomic_refresh => FALSE，让 Oracle 改用TRUNCATE+INSERT /*+ APPEND */模式，跳过事务日志，只读基表不写锁 - 但该参数仅对真正支持 FAST 刷新的物化视图有效；若不满足条件（如缺日志、含聚合），会静默退化为 COMPLETE，反而更慢更锁
- 验证是否真支持 FAST：
SELECT fast_refreshable FROM user_mviews WHERE mview_name = 'MV_SALES'，返回值必须是FAST，不能是DIRLOADDML或UNDEFINED
并行度设置（PARALLELISM）越高，越容易引发锁争用和临时段冲突
很多人以为开并行能加速刷新，但在 11g 中，PARALLELISM > 0 常常适得其反——它会启动多个并行进程同时读取物化视图日志（MLOG$_xxx），而日志表本身是普通堆表，缺乏 (snaptime$$, sequence$$) 复合索引时，并行扫描会触发大量磁盘排序与临时段争用，间接拖慢单个刷新批次，延长持锁时间。
典型表现：
-
v$session_longops显示大量Parallel Query操作卡在Sort Segment -
v$lock中出现多个会话对同一个MLOG$_xxx表持有TX锁 - 刷新过程中基表 DML 响应变慢，即使没直接冲突，也因 undo 回滚段被高并发写入而延迟
实操建议：
- 对大多数 OLTP 场景，设
PARALLELISM => 0反而更稳；尤其当基表 I/O 已是瓶颈时，并行只会加剧争抢 - 若确需并行（如夜间大分区刷新），务必先建索引：
CREATE INDEX idx_mlog_snap_seq ON MLOG$_SALES (snaptime$$, sequence$$) - 禁用并行后，配合
ATOMIC_REFRESH => FALSE，可将刷新锁窗口压缩到秒级（仅 truncate + append 的瞬时表锁）
ON COMMIT 刷新模式本质上就是主表锁的“开关”
ON COMMIT 不是“自动刷新”，而是“每次事务提交时强制触发一次刷新”。这意味着：只要基表有 DML 提交，Oracle 就立刻去查日志、回放变更、更新 MV——整个链路串在业务事务里，必须加锁保障一致性。哪怕只是插入一行，也会触发对物化视图日志表和 MV 基表的行级锁定，极易与后续 DML 形成阻塞闭环。
它和 ON DEMAND 的根本区别在于事务边界：
-
ON COMMIT：刷新与业务事务强绑定，锁生命周期 = 业务事务持续时间 + 刷新耗时 -
ON DEMAND：刷新是独立后台任务，锁生命周期 = 刷新自身耗时，可控、可调度、可降级
所以，除非业务要求毫秒级最终一致性（且能接受写性能折损），否则必须停用 ON COMMIT：
- 重建物化视图时明确指定
REFRESH FAST ON DEMAND - 已有
ON COMMIT的 MV，用ALTER MATERIALIZED VIEW mv_name REFRESH FAST ON DEMAND切换 - 切换后，必须配合定时任务（
DBMS_SCHEDULER）调用DBMS_MVIEW.REFRESH，且务必设置max_run_duration防止卡死
刷新卡住却查不到明显锁，大概率是物化视图日志表本身被争抢
很多 DBA 查 v$locked_object 发现基表没锁，就以为“没锁问题”，其实锁源可能在物化视图日志表（如 MLOG$_SALES）上。FAST 刷新本质是“读日志 → 回放 DML”，当多个刷新任务或高频率 DML 同时写/读日志表时，MLOG$_xxx 会成为热点资源，出现 enq: TX - row lock contention 或 enq: UL - contention（日志表上的用户锁）。
验证方式：
SELECT object_name FROM v$locked_object lo, dba_objects ao WHERE lo.object_id = ao.object_id AND object_name LIKE 'MLOG%'- 查日志表数据量：
SELECT COUNT(*) FROM MLOG$_SALES；若远超日常 DML 量（比如百万级），说明日志积压未消费，刷新已失败多次 - 检查统计信息是否陈旧：
SELECT last_analyzed FROM dba_tables WHERE table_name = 'MLOG$_SALES'；若为空或超过 7 天，GATHER_TABLE_STATS必须全采样执行
修复动作要快准狠：
- 立即清理积压日志：
EXEC DBMS_MVIEW.PURGE_LOG('SALES', 1)（清理 1 天前记录） - 补索引：
CREATE INDEX idx_mlog_sales_ts ON MLOG$_SALES (snaptime$$, sequence$$) - 更新统计信息：
EXEC DBMS_STATS.GATHER_TABLE_STATS(user, 'MLOG$_SALES', estimate_percent => 100)
日志表不是“建了就完事”的静态对象，它是 FAST 刷新的咽喉，它的健康度直接决定锁是否可见、是否可控、是否可预测。
