DBMS_REDEFINITION.REDEF_TABLE仅适用于纯存储属性变更，如切换表空间、启停压缩、LOB类型切换；若涉及逻辑结构修改（如加列、分区调整等），必须使用四步流程。
直接结论：用 dbms_redefinition.redef_table 一键切换表空间最稳，但仅限纯存储属性变更；若还要改分区、加列、调压缩等，必须走 can_redef_table → start_redef_table → copy_table_dependents → finish_redef_table 四步流程。
什么时候该用 REDEF_TABLE 而不是老流程？
它只处理「存储层」改动，不碰逻辑结构。满足以下任意一项，就适合用这个单步过程：
- 只想把表从
USERS换到NEW_TBS表空间（含其索引、LOB 列） - 只想开启/关闭表级压缩（
ROW STORE COMPRESS BASIC或ADVANCED） - 只想把
LOB列从BASICFILE改成SECUREFILE
一旦你同时想加字段、改分区键、或让主键索引变成本地分区索引，REDEF_TABLE 就会静默忽略——它不报错，但也不生效。这时候必须退回四步法。
CAN_REDEF_TABLE 成功不代表真能重定义
执行 EXEC DBMS_REDEFINITION.CAN_REDEF_TABLE('SCHEMA', 'TABLE_NAME'); 返回成功，只说明表没硬性禁令（比如是 SYS 用户下、或含 REF 类型）。但这些隐性拦路虎常在后续步骤爆雷：
- 源表有未提交事务 →
START_REDEF_TABLE会卡住等待，查v$session和v$transaction确认 - 中间表建在目标表空间，但该表空间最大连续空闲块 dba_free_space.bytes 中预估新表大小 →
SYNC_INTERIM_TABLE报ORA-01653 - 原表主键列用了
SYSTIMESTAMP默认值，或触发器里写了SEQUENCE.NEXTVAL→START_REDEF_TABLE可能不报错，但同步后数据不一致
中间表（interim table）建表时最容易错的三处
中间表不是“原表 CREATE TABLE AS SELECT”就能糊弄过去。它必须和原表在类型层面完全对齐：
-
VARCHAR2(100)和VARCHAR2(100 CHAR)视为不一致，START_REDEF_TABLE直接报ORA-14197 - 分区键列（如
ORDER_DATE）不能加NOT NULL约束，哪怕原表该列非空——中间表加了就失败 - 别手动建索引、约束、触发器。这些全交给
COPY_TABLE_DEPENDENTS处理，自己先建反而导致COPY阶段报ORA-14098（索引不匹配）
最后那把锁的时间其实可控，但容易被低估
FINISH_REDEF_TABLE 执行时会拿表级排他锁（X lock），把所有 DML 暂停。这把锁持续时间 ≈ 剩余未同步的增量日志量 + 元数据切换开销。五千万行表若前期已多次 SYNC_INTERIM_TABLE，锁通常在秒级；但如果跳过同步、攒到最后一步再刷，可能卡几十秒甚至更久。业务高峰期前务必做一次预热同步，别等到上线才第一次 SYNC。
