能用但必须严格按步骤执行，漏一步即失败；关键在于识别失败条件而非语法，如无主键、跨schema、SYS/SYSTEM下表、中间表NOT NULL列无默认值等均会导致后续报错。
能用，但必须严格按步骤走，漏一步就卡住或报错；最关键的不是“怎么写”，而是“哪些条件不满足就会失败”。
DBMS_REDEFINITION.CAN_REDEF_TABLE 检查前先确认硬性前提
这个过程不报错 ≠ 表真的能重定义。它只做基础校验，很多隐性限制它不拦——比如表在 SYS/SYSTEM 下、没主键却想用 CONS_USE_PK、中间表新增列带 NOT NULL 约束，都会在后续步骤爆错。
- 必须有主键（或唯一约束），且主键列不能被修改（比如不能在重定义中删主键列、改主键列类型）
- 源表和中间表必须在同一个 schema 下；
SYS和SYSTEM用户下的表直接不支持 - 中间表的结构必须兼容：新增列不能带
NOT NULL（除非给默认值且允许空插入），否则COPY_TABLE_DEPENDENTS会失败 - 执行用户需具备：
EXECUTE_CATALOG_ROLE+CREATE ANY TABLE+ALTER ANY TABLE+DROP ANY TABLE+LOCK ANY TABLE+SELECT ANY TABLE
START_REDEF_TABLE 启动时最常踩的三个坑
这一步看似简单，但参数错一个就进不了下一步。尤其注意 options_flag 和列映射逻辑。
- 没显式指定
options_flag时，默认用主键方式；但如果中间表结构和原表不完全一致（比如少列、多列），必须传DBMS_REDEFINITION.CONS_USE_PK或DBMS_REDEFINITION.CONS_USE_ROWID，否则报ORA-12089 - 如果要用列映射（比如把原表
old_col改名成new_col），必须在col_mapping参数里写成'old_col new_col'这种字符串格式，不能用逗号或等号 - 中间表建好后，千万别手建索引或约束——
COPY_TABLE_DEPENDENTS会自动复制，提前建了反而可能冲突或报ORA-14097
COPY_TABLE_DEPENDENTS 复制依赖对象时 ignore_errors 要慎用
这个过程默认不复制统计信息，也不处理禁用状态的约束；ignore_errors => TRUE 看似省事，实则埋雷。
- 触发器复制失败（比如含
PRAGMA AUTONOMOUS_TRANSACTION）会被跳过，但业务逻辑可能已依赖它 - 索引名重复（如原表有
idx_1，中间表也建了同名索引）会导致复制中断，必须提前清理中间表上的对象 - 权限复制（
copy_privileges => TRUE）只复制直接授给该表的权限，角色权限不会继承，别以为 GRANT 都自动同步了 - 强烈建议先跑一遍
copy_indexes => DBMS_REDEFINITION.CONS_ORIG_PARAMS，再单独检查索引是否都建对了
FINISH_REDEF_TABLE 切换瞬间的锁行为和容错底线
这是唯一真正停服务的环节，但时间可控。关键不是“快”，而是“别让它卡住”。
-
FINISH_REDEF_TABLE会持有一个短暂的 DML 排他锁（X lock），期间所有 INSERT/UPDATE/DELETE 都会阻塞，直到切换完成；SELECT 不受影响 - 锁持续时间取决于未同步的变更量——所以大表务必在
FINISH前多跑几次SYNC_INTERIM_TABLE，尤其在业务低峰期做最后一次同步 - 一旦
FINISH报错（比如空间不足、约束冲突），必须立刻执行ABORT_REDEF_TABLE清理临时对象，否则中间表残留、物化视图日志堆积，下次重定义会直接失败 - 切换完成后，原表变为空壳（结构还在但无数据），中间表变成原名；别忘了手动删掉旧的中间表（
DROP TABLE ...），否则占两倍空间
真正难的从来不是语法，而是判断“现在能不能开始”——比如高水位线回收场景下，MOVE 会锁表，而 DBMS_REDEFINITION 虽然最终要锁一下，但前面所有步骤都可在线运行；可一旦中间表空间不足、或主键被意外删掉，整个流程就停在 START_REDEF_TABLE，连回滚都要手动干预。
