物化视图不支持保留源分区表结构，目标端始终为非分区堆表；ORA-12082禁止ON PREBUILT TABLE使用分区表；需手动建索引或虚拟列模拟分区剪枝，否则查询性能显著下降。
物化视图本身不支持跨库同步分区表的原生分区结构 —— 目标库上的物化视图始终是普通（非分区）表，即使源表是 range/list/hash 分区表。
物化视图能否保留源表的分区定义
不能。Oracle CREATE MATERIALIZED VIEW 语法中没有 PARTITION BY 或类似子句；目标端创建的物化视图一定是堆表（heap table），其段属性、分区键、分区数量、分区边界等全部丢失。
- 你看到的
MV_T表在PROD库里，DBA_TAB_PARTITIONS查不到任何记录 - 即使源表
T在OCM2上按CREATEDATE做了 12 个范围分区，物化视图也只存一份全量数据 -
ON PREBUILT TABLE方式也不能绕过该限制：预建的目标表若本身是分区表，CREATE MATERIALIZED VIEW ... ON PREBUILT TABLE会报错ORA-12082: "table_name" must not be partitioned
分区表同步后如何应对查询性能下降
因为物化视图丢失分区剪枝（partition pruning）能力，原本能快速定位单个分区的查询，现在要全表扫描 MV_T，尤其当数据量达百万级以上时响应明显变慢。
- 必须在物化视图上手动补建关键字段的 B-tree 索引，例如：
CREATE INDEX idx_mv_t_dt ON mv_t(createdate); - 若业务常按时间范围查，且源表按月分区，可在物化视图上加虚拟列 + 函数索引模拟分区逻辑：
ALTER TABLE mv_t ADD (month_key AS (TO_CHAR(createdate, 'YYYYMM'))); CREATE INDEX idx_mv_t_month ON mv_t(month_key); - 避免在物化视图上执行
SELECT * FROM mv_t WHERE createdate >= DATE '2025-01-01'这类无索引支撑的范围扫描
物化视图组（MV Group）对分区表同步有帮助吗
没有实际增益。物化视图组（通过 DBMS_REFRESH.MAKE 创建）仅用于批量刷新多个物化视图，保证事务一致性，它不改变单个物化视图的存储结构或分区行为。
- 组内所有成员仍是非分区表，组刷新只是把
dbms_mview.refresh('MV_A')和dbms_mview.refresh('MV_B')包进一个事务 - 如果你试图把源库多个分区表（如
T_202501,T_202502）各自建物化视图再加入同一组，依然无法实现“按分区增量拉取”——每个物化视图仍依赖各自的日志表，且刷新粒度仍是整表级 - 真正需要分区感知同步，应换用 Oracle GoldenGate 或自定义 PL/SQL +
DBMS_PARALLEL_EXECUTE分片拉取
最易被忽略的一点：很多人以为加了 WITH ROWID 就能高效同步分区表，其实 ROWID 在跨库场景下毫无意义 —— 源库的 ROWID 到目标库完全无效，FAST 刷新实际退化为基于物化视图日志的主键比对，而分区键本身并不参与该比对逻辑。
