Oracle不支持跨实例物化视图并行刷新，仅支持单实例内分区表多分区并行刷新；其核心限制在于DBMS_MVIEW.REFRESH无法跨实例执行DML、MLOG$日志不可共享、且不支持实例前缀的MV名；通过ON PREBUILT TABLE结合并行INSERT与分区剪枝可实现伪跨分区可控刷新。
Oracle 本身不支持“跨节点”物化视图刷新——它没有分布式物化视图的原生并行刷新能力；所谓“跨节点”实际是误读，真实场景中指的是单实例内对**分区表的多分区并行刷新**，或通过应用层调度在多个数据库实例上分别管理不同分区的物化视图。真正的并行发生在单库内部，靠的是 PARALLEL 提示、ATOMIC_REFRESH => FALSE 和底层为普通表的 ON PREBUILT TABLE 结构。
为什么不能跨 Oracle 实例并行刷新物化视图？
Oracle 的 DBMS_MVIEW.REFRESH 过程只能在当前连接的数据库实例内执行 DML（INSERT/DELETE/TRUNCATE），无法自动分发任务到其他实例。即使使用 DB Link 创建远程物化视图，其刷新仍由本地实例发起、串行拉取远程数据，且不支持 PARTITION 级别控制或并行 DML。错误地尝试“跨节点”会导致 ORA-02021（不支持的 DDL 操作）或长时间挂起。
- 物化视图日志（
MLOG$）只存在于基表所在实例，远程实例无法访问变更记录 -
FAST刷新依赖本地MLOG$行与SNAPTIME$$，跨实例时时间戳和 ROWID 不可比对 -
DBMS_MVIEW.REFRESH的list参数只接受本地 MV 名，不支持实例前缀（如db2.mv_sales）
如何用 ON PREBUILT TABLE + 并行 INSERT 实现分区级可控刷新？
这是 TB 级分区表唯一能逼近“伪跨分区并行”的路径：把物化视图注册为已建好的物理表，刷新退化为对普通表的并行 DML 操作，不再受 MV 原子事务约束。
- 先建分区表：
CREATE TABLE mv_sales PARTITION BY RANGE(sale_date) (...)，确保分区键、数量与基表对齐 - 创建索引和统计信息：
CREATE INDEX ix_mv_sales_dt ON mv_sales(sale_date) LOCAL - 注册为物化视图：
CREATE MATERIALIZED VIEW mv_sales ON PREBUILT TABLE REFRESH FAST ON DEMAND AS SELECT * FROM sales - 按需并行填充某分区：
INSERT /*+ APPEND PARALLEL(8) */ INTO mv_sales PARTITION (P202610) SELECT * FROM sales PARTITION (P202610) - 再触发最小粒度
FAST刷新：DBMS_MVIEW.REFRESH('mv_sales', 'F', atomic_refresh => FALSE)，此时只扫该分区对应日志
分区剪枝 + SNAPTIME$$ 对齐才是增量可控的关键
想让刷新真正只影响目标时间段，不能靠物化视图定义里的 WHERE（语法不支持），而要靠手动控制日志范围和分区物理边界。
- 查目标分区 ROWID 范围：
SELECT MIN(ROWID), MAX(ROWID) FROM sales PARTITION (P202610) - 清理过期日志避免全扫：
DBMS_MVIEW.PURGE_LOG('SALES', 1)（保留最近 1 天） - 确保
SNAPTIME$$在刷新前被设为合理起点，例如：UPDATE mlog$_sales SET snaptime$$ = TO_DATE('2026-10-25 00:00:00', 'YYYY-MM-DD HH24:MI:SS') WHERE ...（慎用，需配合锁） - 若用会话上下文驱动过滤（如
SYS_CONTEXT('mv_ctx','end_date')），必须搭配ON PREBUILT TABLE+ 手动INSERT替换，而非依赖REFRESH自动推导
最容易被忽略的一点：并行刷新效果高度依赖底层表是否真正分区且本地索引可用；如果 mv_sales 是堆表或全局索引，PARTITION (P202610) 提示会被忽略，所有并行进程仍可能争抢同一数据块。务必验证执行计划中出现 PARTITION LIST SINGLE 或 INLIST ITERATOR。
