atomic_refresh=true默认触发truncate导致exclusive表锁，改用atomic_refresh=false可降为行级锁，但前提是物化视图必须真实支持fast刷新且物化视图日志有效。
dbms_mview.refresh 的原子性刷新（atomic_refresh => true）默认会加 exclusive 表级锁，这是物化视图刷新引发锁表的最常见原因。想避免阻塞业务 dml，必须绕开这个默认行为。
为什么 atomic_refresh=TRUE 会导致锁表
Oracle 在执行 atomic_refresh => TRUE（默认值）时，会先 truncate 基表，再 insert 新数据。truncate 是 DDL 操作，触发 exclusive 锁，整个物化视图基表在刷新期间不可读写。
- 即使只刷新几万行，锁持续时间 = truncate + insert + 索引重建耗时
-
V$LOCKED_OBJECT中能看到锁模式为6（exclusive），对应被锁的物化视图表名 - 业务查询该物化视图或其基表时，会卡在
enq: TM - contention或enq: TX - row lock contention
改用 atomic_refresh=FALSE 绕过 truncate 锁
设置 atomic_refresh => FALSE 后，Oracle 改用 delete + insert 方式刷新，只对变更行加行级锁（ROW EXCLUSIVE），不阻塞全表读写。
- 前提是物化视图必须支持快速刷新（
FAST），且已建好物化视图日志（MLOG$_xxx） - 执行语句示例：
DBMS_MVIEW.REFRESH('MV_SALES', method => 'F', atomic_refresh => FALSE) - 注意：如果物化视图定义含聚合或连接，
atomic_refresh => FALSE可能报错ORA-12052，需确认是否真支持快速刷新
刷新前检查物化视图是否真支持快速刷新
别只看创建语句写了 REFRESH FAST，得查 Oracle 实际是否认可。否则 atomic_refresh => FALSE 会静默退化为完全刷新，反而更慢更锁。
- 查支持状态：
SELECT mview_name, fast_refreshable FROM user_mviews WHERE mview_name = 'MV_SALES'，返回FAST才可靠 - 查缺失依赖：
SELECT * FROM user_mview_analysis WHERE mview_name = 'MV_SALES'，重点关注capable_flag = 'N'的项 - 物化视图日志必须存在且未失效：
SELECT log_table FROM user_mview_logs WHERE master = 'SALES'
刷新窗口期仍需防长事务拖累
即使用了 atomic_refresh => FALSE，若刷新本身耗时太久（比如几十秒以上），仍可能因 delete/insert 积累大量 undo，导致其他会话在查询旧版本数据时等待 read consistency，间接表现为“像锁住了”。
- 监控刷新实际耗时：
SELECT start_time, end_time, elapsed_seconds FROM user_mview_refresh_times WHERE name = 'MV_SALES' ORDER BY start_time DESC - 避免在业务高峰执行；大物化视图建议拆成多个小 MV 分批刷
- 物化视图基表上确保有合适索引（尤其 on commit 刷新依赖的 join key 和 filter 字段）
物化视图刷新锁表问题的核心不在“要不要刷新”，而在于“用什么方式刷新、以及这个方式是否真的被 Oracle 当作快速刷新来执行”。atomic_refresh => FALSE 不是银弹，它依赖底层快速刷新能力真实可用——这点最容易被忽略，也最常导致修复后仍出问题。
