oracle物化视图不支持在线重建，因drop会立即删除底层物理表导致查询失败；零中断重建需通过原子重命名同结构临时表实现，前提为单表、结构兼容且权限完备。
Oracle物化视图本身不支持“在线重建”（即 DROP + CREATE 原地替换），直接 DROP MATERIALIZED VIEW 会立刻使查询失败——因为对象瞬间消失，不是高可用操作。
为什么不能直接 DROP + CREATE？
物化视图是真实存在的数据库对象，其底层对应一张物理表（user_tables 中可查）。一旦 DROP，该表立即删除，所有依赖它的查询、视图、应用 SQL 都会报 ORA-00942: table or view does not exist。这不是刷新延迟问题，而是对象级中断。
- 即使你用
BUILD DEFERRED创建新 MV，旧 MV 还没删时两个对象并存，但业务查询通常硬编码了旧名，无法自动切流 -
ON PREBUILT TABLE方式虽能复用表结构，但前提是目标表已存在且结构完全兼容；若字段类型、顺序、约束不同，CREATE MATERIALIZED VIEW ... ON PREBUILT TABLE会直接报错ORA-12091: cannot create materialized view log on prebuilt table或ORA-12093: invalid DDL operation on prebuilt table - 跨 schema 或跨 database link 的物化视图，重建过程还涉及权限、dblink 可达性等额外依赖，失败概率更高
真正可行的“零中断重建”路径：原子切换表名
核心思路是：用新物化视图填充一张**同结构、同权限、同索引**的临时表，再通过 RENAME 原子交换表名。Oracle 的 RENAME 是 DDL 瞬时操作，对查询完全透明。
- 前提：物化视图必须基于单表、无复杂连接，且你有权限在目标 schema 下建普通表和索引
- 步骤如下：
— 创建空目标表（与原 MV 结构一致）：CREATE TABLE mv_target_new AS SELECT * FROM mv_old WHERE 1=0
— 添加必要索引、约束、统计信息（尤其主键或唯一索引，否则后续 FAST 刷新可能失败）
— 创建新物化视图指向该表：CREATE MATERIALIZED VIEW mv_target_new ON PREBUILT TABLE REFRESH FAST AS SELECT ...
— 手动触发首次刷新：DBMS_MVIEW.REFRESH('mv_target_new', 'F')
— 确认数据一致后，原子切换：RENAME mv_old TO mv_old_bak; RENAME mv_target_new TO mv_old; - 注意：
RENAME不影响正在执行的查询——旧查询继续读原表（现名mv_old_bak），新查询立刻命中新表（现名mv_old），无锁、无等待、无报错
FAST刷新重建时最容易踩的坑
想用 REFRESH FAST 快速同步增量，却卡在第一次刷新失败，常见原因不是语法错，而是日志与定义不匹配。
- 基表物化视图日志缺失必需列：例如物化视图查询中用了
ROWID，但日志没建WITH ROWID；或用了主键字段，但日志没加WITH PRIMARY KEY - 基表没有主键或唯一约束：
ORA-12015直接报出，FAST 刷新不可用，只能退化为 COMPLETE —— 而 TB 级表 COMPLETE 刷新可能耗时数小时，期间新表为空，切换后业务查不到数据 - 物化视图定义含禁止项：如
SYSDATE、ROWNUM、子查询、聚合函数，强制禁用 FAST，但错误常在CREATE时不报，直到REFRESH才暴露 - 日志未启用
INCLUDING NEW VALUES：导致无法捕获 UPDATE 后的新值，FAST 刷新只处理 INSERT/DELETE，UPDATE 被忽略
大表重建时性能与资源的关键控制点
即使走原子切换，TB 级物化视图的首次填充仍可能拖慢系统，重点不在“是否中断”，而在“是否抖动”。
- 初始数据加载不用
REFRESH COMPLETE：它隐式走TRUNCATE + INSERT /*+ APPEND */，但并发高时易争抢 undo 和 temp 表空间。改用显式并行插入：INSERT /*+ APPEND PARALLEL(8) */ INTO mv_target_new SELECT ... FROM source - 禁用日志写入（
NOLOGGING）仅限非归档模式或可接受丢失的场景；生产环境开启归档时，NOLOGGING操作仍会产生 minimal redo，且备份链可能断裂 - 刷新调度避开高峰：用
NEXT SYSDATE + 1/24/4（15 分钟）不如NEXT TRUNC(SYSDATE)+1/2（每天凌晨 2 点），避免日志堆积和刷新排队引发连锁延迟 - 如果基表本身是分区表，务必手动给新表（
mv_target_new）也建相同分区策略，否则后续按时间范围查询会全表扫描，性能反降
真正麻烦的从来不是“怎么切”，而是切之前没验证好日志完备性、结构一致性、权限覆盖范围——这些点一漏，RENAME 完就立刻出错，比直接 DROP 还难回滚。
