物化视图刷新锁表因ATOMIC_REFRESH=>TRUE默认启用原子刷新（INSERT新数据+DELETE旧数据），全程持SS锁阻塞DML；设FALSE虽不锁表但DROP重建导致MV短暂不可用，报ORA-00942。
物化视图刷新时为什么锁表？
oracle 在执行 refresh（尤其是 complete）时，默认用 atomic_refresh => true，即原子刷新：先 insert /*+ append */ 新数据，再 delete 旧数据。这个过程全程持有物化视图上的 ss（share subexclusive）锁，阻塞其他 dml（如 update、delete），但允许 select。如果基表大、lob 多或网络慢，锁可能持续几分钟甚至更久。
ATOMIC_REFRESH => FALSE 真的“不可见”？
设成 FALSE 后，Oracle 改用“先 DROP + CREATE AS SELECT”方式，确实不锁原 MV 表——因为原表已不存在。但代价是：刷新期间任何对物化视图的 SELECT 都会报 ORA-00942: table or view does not exist。这不是“不可见刷新”，而是“彻底消失期”。
- 适用场景仅限：查询流量极低的维护窗口，或应用层能捕获该错误并自动降级（比如查不到就回源基表）
- 不能用于
ON COMMIT刷新，该模式强制要求ATOMIC_REFRESH => TRUE - 若物化视图被其他对象（如视图、同义词）依赖，
DROP会导致依赖失效，需手动重建
真正降低锁定影响的实操组合
没有“完全不可见”的刷新，只有把锁的影响压到最低。关键不是关锁，而是缩小时长和范围：
- 优先用
FAST刷新：只要满足日志条件（WITH ROWID+ 所有 SELECT 列在日志中），它只锁 MV 几秒，且不阻塞查询 - 避开 LOB 字段：含
CLOB/BLOB的物化视图只能COMPLETE，必须剔除这些列，或改用应用缓存替代 - 分批次刷新大分区：对按时间分区的 MV，用
DBMS_MVIEW.REFRESH的list参数指定单个分区名，避免全表锁 - 禁用并行刷新：
PARALLELISM => 0可减少临时段争用，反而让单次刷新更快更稳（尤其在 I/O 瓶颈时）
调度刷新时最容易忽略的超时陷阱
用 DBMS_SCHEDULER 自动跑 REFRESH，却不设 job_action 超时，是线上事故高发点。LOB 大或统计信息过期时，一个 COMPLETE 刷新可能卡住 40 分钟，导致后续任务堆积、调度链断裂。
- 务必在 job 定义里加
max_run_duration（例如'+000 00:30:00'） - 失败后别静默重试：配置
max_failures => 1，触发告警而不是反复刷库 - 监控
DBA_MVIEWS.LAST_REFRESH_DATE和DBA_MVIEW_LOGS.LOG_TABLE增长速度，提前发现日志膨胀拖慢 FAST
锁本身不可绕过，但锁的时长、范围和后果，全由你控制——重点不在“要不要锁”，而在“锁多狠、锁多久、谁来扛”。
