物化视图刷新查不到新数据，需设ATOMIC_REFRESH=FALSE实现Out-of-Place刷新：先建临时MV再原子切换指针，但要求含ROWID/主键、禁用ON COMMIT，否则报ORA-12057或ORA-32313。
物化视图刷新时查不到新数据？先看刷新类型是不是 ATOMIC_REFRESH=FALSE
默认情况下，oracle 物化视图刷新是原子的（atomic_refresh=true），意味着整个刷新过程锁住基表、清空旧数据、再插入新数据——这期间查询会看到空状态或阻塞，不是“读一致”的假象，而是真实中断。如果你希望查询始终能读到某一套完整快照（哪怕稍旧），就得关掉原子性，启用 out-of-place 刷新。
实操建议：
-
DBMS_MVIEW.REFRESH调用时显式传入atomic_refresh => FALSE，不能依赖默认值 - 必须确保物化视图基于单个分区表或支持快速刷新的联结视图，否则
ATOMIC_REFRESH=FALSE会直接报错ORA-12057: materialized view is not fast refreshable - 底层会新建一个临时物化视图（命名类似
MV_NAME_SNAP_XXXX），刷新完成后原子切换指针，原视图查询不受影响
ATOMIC_REFRESH=FALSE 的硬性前提：物化视图必须带主键或 ROWID 且禁用 ON COMMIT
Out-of-Place 刷新本质是“先建后切”，它依赖物化视图能独立存在、不与基表强耦合。所以 Oracle 强制要求：物化视图定义里必须包含基表的 ROWID 或明确的主键列，否则无法保证新旧版本间行级对应关系；同时，ON COMMIT 刷新模式和 ATOMIC_REFRESH=FALSE 互斥——因为提交触发的刷新没法“先建后切”。
常见错误现象：
- 执行刷新时报
ORA-32313: REFRESH FAST of "OWNER"."MV_NAME" unsupported when ATOMIC_REFRESH is FALSE，大概率是没在 SELECT 中显式写出基表ROWID - 明明写了
ROWID还报错？检查是否用了视图嵌套、表达式列或DISTINCT——这些会让 Oracle 认为无法保证行唯一性 - 试图在
ON COMMIT物化视图上设ATOMIC_REFRESH=FALSE，会直接被 PL/SQL 拒绝，连调用都过不去
刷新卡住或变慢？检查临时段空间和并行度是否匹配 ATOMIC_REFRESH=FALSE 行为
Out-of-Place 刷新要同时维护两份数据（旧 MV + 新建临时 MV），对临时表空间压力比原子刷新大得多。而且它默认不继承会话的并行设置，容易误以为“没生效”。
性能相关要点：
- 确保
TEMP表空间有足够空闲空间，尤其当物化视图含大文本或 XMLType 列时，临时段可能膨胀数倍 - 显式指定并行度：
parallelism => 4，否则即使会话开了ALTER SESSION ENABLE PARALLEL DML，DBMS_MVIEW.REFRESH仍按串行跑 - 刷新过程中监控
V$SORT_USAGE和DBA_SEGMENTS（查临时 MV 名称），避免因空间不足导致刷新失败后残留临时对象
为什么切换瞬间还是查到部分新数据、部分旧数据？那是没理解 “原子切换” 的粒度
ATOMIC_REFRESH=FALSE 的“原子”只作用于物化视图对象本身的字典指针切换，不保证你 SQL 查询中涉及的其他表、同义词或 DB Link 同步更新。如果查询语句里混用了基表别名、中间视图，或者物化视图本身依赖另一个正在刷新的 MV，就可能出现跨 MV 数据不一致。
容易被忽略的地方：
- 物化视图 A 依赖物化视图 B，B 用
ATOMIC_REFRESH=FALSE刷新中，A 却还在读 B 的旧版本——这种链式依赖不会自动协调 - 应用层用了连接池，某些连接缓存了旧执行计划，切换后首次查询仍走老 plan，可能命中已失效的 rowid 或统计信息
- 没有配
QUERY_REWRITE_ENABLED=TRUE且 SQL 没走重写路径时，哪怕 MV 切换了，查询还是扫基表，根本没用上新 MV
