物化视图在oracle 19c中无法保留源表分区结构，目标端必为堆表；create materialized view不支持partition by子句，on prebuilt table方式亦被ora-12082禁止。
物化视图无法保留源表分区结构，目标端必为堆表
oracle 19c 的 create materialized view 语法不支持 partition by 或任何分区定义子句。无论源表是 range、list 还是 hash 分区，物化视图在目标库中始终创建为普通堆表（heap table）。执行 select * from dba_tab_partitions where table_name = 'mv_sales' 在目标库查不到任何记录，这是正常行为，不是配置错误。
更关键的是：ON PREBUILT TABLE 方式也无法绕过该限制——若你提前在目标库建好一个分区表并试图绑定物化视图，Oracle 会直接报错 ORA-12082: "mv_sales" must not be partitioned。
跨库同步必须依赖 DBLINK，且刷新粒度是行级而非分区级
分区表的“增量同步”常被误解为“只刷某个分区”，但 Oracle 物化视图的 FAST 刷新机制根本不识别分区信息。它只认 MLOG$_sales 日志里的 ROWID 或主键 + DMLTYPE$$ 字段，所有变更都按行记录，与这些行原本落在 P202501 还是 P202502 无关。
- 源库必须启用物化视图日志：
CREATE MATERIALIZED VIEW LOG ON sales WITH PRIMARY KEY, SEQUENCE INCLUDING NEW VALUES（INCLUDING NEW VALUES不可省，否则 UPDATE 后新值丢失） - 目标库需建有效 DBLINK，且连接用户对源表有
SELECT权限 - 物化视图定义中不能含
SYSDATE、ROWNUM、TO_DATE('2025-01-01',...)等非确定性表达式，否则自动退化为 COMPLETE 刷新 - 即使源表有局部索引，若查询谓词未落在分区键上，优化器可能跳过快速刷新路径
丢失分区剪枝后，必须手动补索引或虚拟列
源表按 sale_date 分区，查询 WHERE sale_date BETWEEN DATE '2025-03-01' AND DATE '2025-03-31' 原本秒出，同步到物化视图后变成全表扫描——因为目标表无分区元数据，也无对应索引。
必须立即执行：
-
CREATE INDEX idx_mv_sales_dt ON mv_sales(sale_date)（最基础、最有效） - 若业务按年月高频过滤，可加虚拟列：
ALTER TABLE mv_sales ADD (year_month AS (TO_CHAR(sale_date, 'YYYYMM')))，再建索引：CREATE INDEX idx_mv_sales_ym ON mv_sales(year_month) - 避免在无索引字段上做范围扫描，例如
SELECT * FROM mv_sales WHERE status = 'SHIPPED'若status未建索引，性能会断崖下跌
别信“分区级增量刷新”，真正需要时得换技术栈
有人尝试把源库每个分区单独建一张表（sales_p202501, sales_p202502），再分别为其建物化视图并加入同一 MV Group——这依然无效。MV Group 只保证多个刷新操作事务一致，不改变单个物化视图的刷新逻辑，也不会让 DBMS_MVIEW.REFRESH 自动识别“只拉 P202501 的变更”。
如果你的场景真要求按分区边界做增量拉取（比如只同步上个月分区、跳过历史冷数据），物化视图不是解法。应转向：
- Oracle GoldenGate：支持表级+分区键条件过滤
- 自定义 PL/SQL +
DBMS_PARALLEL_EXECUTE：按sale_date范围分片，构造动态 SQL 拉取 - 外部 ETL 工具（如 ODI、DataStage）配合时间戳字段做增量抽取
最容易被忽略的一点：跨库场景下，WITH ROWID 完全失效——源库的 ROWID 在目标库无意义，且分区表发生分裂或移动后，ROWID 会批量失效。务必用 PRIMARY KEY 做刷新依据。
