Oracle不支持分布式分区表及主站点刷新机制；跨库物化视图刷新无法同步分区结构，需手动协调本地分区表与远程MV，且仅COMPLETE刷新或带谓词的分批次FAST刷新可行。
oracle物化视图本身不支持“分布式分区表”的原生概念，也没有“主站点刷新”这一内置机制；所谓分布式场景下的分区表刷新，本质是跨数据库的物化视图（即“远程 mv”）+ 本地分区表组合使用时的手动协调问题。
物化视图跨库刷新时，分区信息不会自动同步
当你在远程数据库（如 DB_LINK 指向的 site_b）上基于一张分区表创建物化视图时，DBMS_MVIEW.REFRESH 只能拉取数据，无法识别或传递源端的分区结构。目标端 MV 表默认是普通堆表，即使你手动按分区建了本地分区表，Oracle 也不会自动把 sales_p_202404 的变更只刷到对应分区——它只会全量 insert 或 merge 到整个 MV 表。
- 远程基表若为分区表，其物化视图日志（
MLOG$）仍建在远程库，本地无法直接扫描该日志做快速刷新 -
REFRESH FAST ON DEMAND在跨库场景下基本不可用：ORA-12008 + ORA-02068 等错误常见，因远程日志元数据不可见 - 唯一可靠方式是
REFRESH COMPLETE或分批次REFRESH FAST配合本地日志 + 手动谓词过滤（见下一条）
想实现“主站点驱动分区级刷新”，必须放弃远程 MV，改用本地 MV + DBLINK 查询 + 分区裁剪
真正可行的模式是：在本地库建一个基于 SELECT * FROM sales@site_b 的物化视图，但要求这个查询能触发分区裁剪（即 WHERE 条件含分区键），且本地基表（或中间表）按相同策略分区。
- 确保远程查询带明确分区谓词，例如：
WHERE dt >= DATE '2024-04-01' AND dt ，否则执行计划里partition start/end显示ALL，就白搭 - 本地 MV 必须
BUILD IMMEDIATE且启用QUERY REWRITE，否则优化器不信任分区裁剪结果 - 刷新时用
list => 'mv_sales_apr,mv_sales_may'分别调用，而非刷整个 MV；每个子 MV 对应一个分区范围 - 所有子 MV 共享同一张远程物化视图日志（
ON sales@site_b），但日志必须含WITH ROWID, SEQUENCE, INCLUDING NEW VALUES
ATOMIC_REFRESH=FALSE 在跨库刷新中极危险，不要开
本地执行 DBMS_MVIEW.REFRESH(..., atomic_refresh => FALSE) 会尝试 TRUNCATE 本地 MV 表再 INSERT /*+ APPEND */，但跨库查询无法保证事务原子性——一旦网络中断或远程库不可用，本地表就空了，且无回滚路径。
- 跨库场景下必须保持
ATOMIC_REFRESH => TRUE（默认），靠MERGE或INSERT/UPDATE/DELETE语句逐条同步，虽慢但可控 - 若真要提速，应在远程库侧做文章：比如在
site_b上建好按月分区的物化视图，再让本地通过 DBLINK 查这些已预聚合的 MV，而不是直查大基表 - 检查
V$SESSION_WAIT中是否存在大量SQL*Net message from dblink等待，这是跨库刷新卡顿的典型信号
最容易被忽略的一点：远程库上的物化视图日志时间戳（snaptime$$）精度是秒级，而本地刷新任务若在同秒内并发触发，可能漏掉部分变更——建议错开至少 2 秒，或在远程日志表上加 CREATE INDEX idx_mlog_time ON mlog$_sales (snaptime$$) TABLESPACE fast_io_ts; 加速定位。
