复合分区表迁移不能直接用expdp/impdp全表导出，应按主分区+子分区两级拆解手动迁移；MOVE/EXCHANGE PARTITION适用性极窄；可传输表空间需降级为RANGE分区再操作；LogMiner解析DML不稳定，推荐GoldenGate。
复合分区表迁移不能只用 expdp/impdp 直接导出整个表
直接对复合分区表（比如 range-list 或 range-hash）执行全表 expdp，容易触发隐式全表扫描、lob 处理卡顿、分区元数据不一致等问题。尤其当子分区数量多（如每个主分区下有 64 个子分区），expdp 会逐个打开子分区段，导致导出时间陡增，且无法并行控制粒度。
真正高效的做法是按「主分区 + 子分区」两级拆解，手动构造迁移路径：
- 先查清分区结构：
SELECT table_name, partition_name, subpartition_count FROM user_tab_partitions WHERE table_name = 'YOUR_TABLE'; - 对每个主分区，用
QUERY参数限定范围，例如：QUERY=YOUR_TABLE:"WHERE partition_name='P2024_Q1'"（需配合EXCLUDE=PARTITION避免重复导出） - 子分区级导出必须用
TABLES指定完整名称，如TABLES=YOUR_TABLE:P2024_Q1_SUB1，不能只写表名 - 导出时务必加
COMPRESSION=ALL和PARALLEL=4，否则子分区段压缩效率低、I/O 成瓶颈
MOVE PARTITION 与 EXCHANGE PARTITION 的适用边界很窄
ALTER TABLE ... MOVE PARTITION 看似能在线迁移，但对复合分区表几乎不可用：它只支持移动主分区，不支持子分区；一旦表含 LOB 列或位图索引，MOVE 会失败并报 ORA-14285；且移动后索引失效，重建成本高。
EXCHANGE PARTITION 更适合“冷切换”场景，即目标端已有结构一致的非分区表，且数据已预加载。但它要求源/目标表的列顺序、数据类型、约束完全一致，连 NOT NULL 属性都不能差——实际中极少满足。
真正可控的替代方案是：
- 在目标库建好同结构的复合分区表（注意
SUBPARTITION TEMPLATE必须显式定义） - 用
INSERT /*+ APPEND */ INTO ... SELECT按子分区批量插入，每批控制在 100 万行内，避免 undo 膨胀 - 插入后立即
DBMS_STATS.GATHER_TABLE_STATS，否则 CBO 可能选错执行计划
可传输表空间（TTS）对复合分区表的支持有硬限制
Oracle 官方文档明确指出：TRANSPORTABLE=ALWAYS 在 12c 及以后版本才支持复合分区表的 TTS 迁移，且要求源库和目标库字符集、块大小、平台字节序完全一致。若跨平台（如 Linux → AIX），即使启用了 CONVERT，子分区的物理布局仍可能错乱，校验失败率极高。
更现实的 TTS 路径是分层剥离：
- 先将复合分区表降级为普通 RANGE 分区表（用
ALTER TABLE ... MERGE SUBPARTITIONS合并所有子分区） - 再对主分区逐个设为只读，执行
ALTER TABLESPACE ... READ ONLY - 最后用
DATAFILE级拷贝 +IMPDP TRANSPORT_DATAFILES导入 - 导入后立刻用
ALTER TABLE ... SPLIT PARTITION恢复子分区结构（需提前准备好 DDL 脚本）
这个流程绕开了子分区元数据解析难题，但需要停业务窗口来执行 MERGE 和 SPLIT。
增量同步时，LogMiner 对复合分区表的 DML 解析不稳定
用 LogMiner 捕获复合分区表的变更时，SQL_REDO 字段常缺失子分区名，导致 UPDATE 或 DELETE 语句还原成全表操作，同步到目标库后数据错乱。这是 Oracle 19c 以前版本的已知缺陷（Bug 27959112）。
临时规避方法只有两个：
- 改用
DBMS_LOGMNR.CONTINUOUS_MINE+ 自定义解析逻辑，在V$LOGMNR_CONTENTS中过滤SEG_NAME和SEG_TYPE_NAME，拼出带子分区名的完整 SQL - 放弃 LogMiner，改用 GoldenGate，其
DEFGEN工具能正确识别复合分区的OBJECT_ID和DATA_OBJECT_ID，确保 DML 精确路由
别低估子分区名在 DML 中的权重——少一个 @SUB1，就可能让一条更新落在错误的物理段上，而这种错误在校验时极难发现。
