如何通过DBMS_REDEFINITION在线重定义Oracle表空间解决严重碎片化问题？

本文共计876个文字，预计阅读时间需要4分钟。

相关专题：

直接说结论：dbms_redefinition 不是用来“处理表空间碎片”的，它是用来在线重定义表结构的工具；想整理碎片，优先用 alter table ... shrink space，只有在 shrink 不可用（比如非 assm 表空间、含 lob 且是 basicfile）时，才考虑 dbms_redefinition 作为备选方案。

为什么 DBMS_REDEFINITION 不是碎片整理的首选

它本质是“重建一张逻辑等价的新表”，过程包括：建空表 → 复制数据 → 同步增量 → 切换依赖 → 清理旧段。虽然结果上能消除碎片（因为新表从头写入），但代价极高：

• 需要双倍临时空间（新表 + 中间物化视图日志）
• 必须有足够权限（EXECUTE_CATALOG_ROLE + SELECT on 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)），其碎片依旧存在