oracle 12.2+ 支持 alter table ... modify partition by 在线转换，但仅限简单结构；生产环境必须用 dbms_redefinition，它才支持虚拟列、lob、多索引等复杂场景。
直接结论：oracle 12.2+ 可用 alter table ... modify partition by 在线转换，但仅限简单结构；生产环境强烈建议用 dbms_redefinition——它才是唯一能真正支撑高可用、带虚拟列/lob/多索引等复杂表的方案。
ALTER TABLE MODIFY PARTITION BY 能不能直接用？
能，但非常容易报错，不是语法对就万事大吉：常见失败场景包括：
• 原表含 TOTAL_AMOUNT GENERATED ALWAYS AS (QUANTITY * UNIT_PRICE) VIRTUAL —— MODIFY PARTITION BY 不支持虚拟列作分区键，也不允许目标分区键是虚拟列
• 分区键列（如 ORDER_DATE）原表未设 NOT NULL，而你建分区时加了该约束 → 报 ORA-14097
• 表上有全局唯一索引，但 UPDATE INDEXES 子句没显式列出 → ORA-14098
• 使用 LIST 或 HASH 分区 → 该语法只支持 RANGE 和 INTERVAL
• 表依赖物化视图日志或 REF 类型列 → 直接拒绝执行，不给明确提示
DBMS_REDEFINITION 启动前必须验证的三件事
跳过校验等于埋雷，CAN_REDEF_TABLE 返回成功 ≠ 真能跑通：
• 执行 EXEC DBMS_REDEFINITION.CAN_REDEF_TABLE('SZR', 'CUSTOMER_ORDERS'); 后，手动确认：表有主键（不是唯一索引）、无 LONG/BFILE 列、分区键列（如 CREATE_TIME）已存在且非虚拟列
• 检查权限：当前用户需有 EXECUTE_CATALOG_ROLE，且对原表和中间表都有 SELECT、INSERT、UPDATE、DELETE
• 预估空间：临时表 + 原表数据 ≈ 2×原表大小，TEMP 表空间也要预留足够排序空间（尤其当同步期间有大量 DML）
中间表建表时最容易写错的细节
中间表不是复制粘贴原 DDL 就完事：
• 字段定义必须完全一致：VARCHAR2(120) 和 VARCHAR2(120 CHAR) 视为不同类型，START_REDEF_TABLE 会报 ORA-14197
• 分区键列禁止加 NOT NULL 约束（哪怕原表有），否则启动重定义失败
• 不要提前建索引、约束、触发器——全交给 COPY_TABLE_DEPENDENTS 处理，自己建反而导致冲突
• 示例中间表语句中，PARTITION BY RANGE (CREATE_TIME) INTERVAL (NUMTOYMINTERVAL(1,'MONTH')) 是安全选择，比手写一堆 P202501、P202502 更可靠
同步完成后 FINISH_REDEF_TABLE 的真实影响
这一步看似原子，但业务感知取决于增量变更量：
• FINISH_REDEF_TABLE 会短暂加 SX 锁，所有新 DML 进入等待队列
• 等待时长 = 从上次 SYNC_INTERIM_TABLE 到现在未同步的变更量 × 应用并发压力
• 若中间表和原表间积压了数万条 DML，切换可能卡住几秒，对强实时系统就是风险点
• 正确做法：在低峰期执行最后一次 SYNC_INTERIM_TABLE，立刻跟 FINISH_REDEF_TABLE，不要间隔
分区设计本身比语法更重要。用 USER_ID 做 RANGE 分区，结果各分区数据量差 10 倍，查询照样扫全表；用日期字段却选 LIST 分区，新增月份就得人工 ALTER TABLE ADD PARTITION。这些坑，代码写得再准也救不回来。
