DBMS_REDEFINITION不是碎片整理首选，而是在线重定义表结构的工具；整理碎片应优先用ALTER TABLE ... SHRINK SPACE，仅在非ASSM表空间或含BASICFILE LOB等SHRINK不可用时才将其作为备选。
直接说结论：dbms_redefinition 不是用来“处理表空间碎片”的，它是用来在线重定义表结构的工具；想整理碎片，优先用 alter table ... shrink space，只有在 shrink 不可用（比如非 assm 表空间、含 lob 且是 basicfile）时，才考虑 dbms_redefinition 作为备选方案。
为什么 DBMS_REDEFINITION 不是碎片整理的首选
它本质是“重建一张逻辑等价的新表”，过程包括：建空表 → 复制数据 → 同步增量 → 切换依赖 → 清理旧段。虽然结果上能消除碎片（因为新表从头写入），但代价极高：
- 需要双倍临时空间（新表 + 中间物化视图日志）
- 必须有足够权限（
EXECUTE_CATALOG_ROLE+SELECTon source） - 对大表而言，同步阶段可能持续数小时，期间 DML 虽可继续，但延迟会明显上升
- 不解决表空间级碎片——哪怕单个表重定义完了，其他高水位线（HWM）偏高的表依然拖累全表扫描性能
什么情况下才真得用 DBMS_REDEFINITION 整理碎片
只在以下条件**同时满足**时才考虑：
- 表所在表空间是
DICTIONARY管理（查dba_tablespaces的extent_management字段），导致SHRINK SPACE直接报错ORA-10637 - 表含
BASICFILE LOB列（SHRINK SPACE对其完全无效） - 业务无法接受
ALTER TABLE ... MOVE带来的锁表时间（MOVE 后索引全失效，重建又耗时） - 你恰好需要顺便改结构（比如加列、改分区、转为压缩表）——这时碎片整理只是顺带收益
注意：DBMS_REDEFINITION 本身不处理索引碎片，切换后仍需手动 ALTER INDEX ... REBUILD ONLINE。
执行 DBMS_REDEFINITION 前必须验证的三件事
跳过任一检查，都可能卡在 CAN_REDEF_TABLE 或中途失败：
- 确认表支持重定义：
EXEC DBMS_REDEFINITION.CAN_REDEF_TABLE('SCHEMA_NAME', 'TABLE_NAME');—— 若报错ORA-12089（无主键/伪主键）或ORA-12090（含不支持类型），立刻停手 - 检查源表是否有未提交事务或长时间运行的查询（
v$transaction,v$session），否则START_REDEF_TABLE会等待 - 确保目标表空间有足够空闲块（不是仅看百分比，而是
dba_free_space中最大连续块 ≥ 预估新表大小），否则SYNC_INTERIM_TABLE会因无法分配 extent 报ORA-01653
碎片整理效果最易被忽略的点
即使成功完成 DBMS_REDEFINITION，也别以为万事大吉：
- 统计信息不会自动更新——必须立刻执行
DBMS_STATS.GATHER_TABLE_STATS，否则优化器仍按旧NUM_ROWS和BLOCKS估算，执行计划可能更差 - 原表段（old table segment）不会立即释放，要等
DROP INTERIM TABLE后才真正归还空间；若忘记这步，表空间使用率毫无变化 - LOB 段如果没单独处理（比如
SECUREFILE需用ALTER TABLE ... MODIFY LOB (...) (SHRINK SPACE)），其碎片依旧存在
