ALTER TABLE ... MOVE 不能在线执行，因其需持有表级排他锁、重写所有数据并使索引失效；真正支持在线的操作是 SHRINK SPACE（需先启用行移动且表空间为ASSM）或 DBMS_REDEFINITION。
ALTER TABLE ... MOVE 不能在线执行，所谓“MOVE ONLINE”是常见误解。Oracle 官方从未提供 MOVE 的在线版本；它始终需要排他锁（EXCLUSIVE），DML 会被阻塞，只允许 SELECT。
如果你看到有人提“MOVE ONLINE”，大概率混淆了以下三类操作：
- 错把
SHRINK SPACE当成MOVE - 把
DBMS_REDEFINITION（在线重定义）简称为“在线 MOVE” - 或误用了第三方工具/自定义脚本的包装层
下面直说关键点：
为什么MOVE一定不是在线的？
执行 ALTER TABLE t MOVE 时，Oracle 必须：
- 锁定整张表（TM 级别 EXCLUSIVE 锁）
- 读取原段所有数据块，逐行插入新位置
- 原段物理地址失效，所有 ROWID 变更
- 索引立即变为 UNUSABLE 状态（查主键会直接报 ORA-01502）
这些动作天然无法与并发 DML 共存。哪怕表只有 10 行，锁也存在 —— 只是持续时间极短，容易被误判为“几乎没影响”。
SHRINK SPACE 才是真正支持在线的碎片整理方式
前提是满足两个硬性条件：
- 表已启用行移动：ALTER TABLE t ENABLE ROW MOVEMENT
- 表位于自动段空间管理（ASSM）的表空间中（检查 DBA_TABLESPACES.SEGMENT_SPACE_MANAGEMENT = 'AUTO'）
常用组合：
-
ALTER TABLE t SHRINK SPACE COMPACT：只整理碎片、不降高水位（HWM），可随时执行，DML 仅在最后几毫秒短暂阻塞 -
ALTER TABLE t SHRINK SPACE：整理 + 降 HWM + 释放空间，需更多资源，业务低峰期执行更稳妥 -
ALTER TABLE t SHRINK SPACE CASCADE：连带收缩所有相关索引（等价于对每个索引执行SHRINK SPACE），避免后续单独处理索引
注意：SHRINK 不重建索引结构，只更新叶节点中的 ROWID 映射，所以索引保持 VALID 状态 —— 这是它和 MOVE 最本质的区别。
LOB 字段让MOVE和SHRINK都变复杂
如果表含 LOB 列（尤其是 BASICFILE 类型），必须额外注意：
- SHRINK SPACE 对 LOB 段无效，即使加 CASCADE 也不管用
- MOVE 若不显式声明 LOB 子句，只会迁移表段，LOB 段原地不动（SYS_LOB* 段仍占 200GB，但表里已空）
- 正确写法必须带 LOB (col_name) STORE AS ...，例如：ALTER TABLE t MOVE LOB (content) STORE AS (TABLESPACE ts_new)
- MOVE 后所有索引（含 LOB 索引）全部失效，必须 REBUILD，且建议加 ONLINE 减少锁影响
漏掉 LOB 子句，是生产环境最常导致“空间没释放”“应用查询失败”的操作失误。
真正想在线操作，该用DBMS_REDEFINITION
这是 Oracle 唯一官方支持的“逻辑在线重定义”机制，适合大表、不能停 DML 的场景：
- 要求主键或唯一约束（或启用 CONS_USE_ROWID）
- 中间表必须干净（无触发器、无物化视图日志等干扰对象）
- FINISH_REDEF_TABLE 后旧段才释放，期间双写、同步延迟可控
- 但它不是“MOVE”，而是新建一个逻辑等价表并原子切换，耗时长、步骤多、依赖检查严
简单说：要快、能停机 → 用 MOVE（配 PARALLEL + NOLOGGING）
要在线、能接受复杂度 → 用 DBMS_REDEFINITION
要轻量、LOB 少、HWM 高 → 优先试 SHRINK SPACE
真正容易被忽略的，是 ENABLE ROW MOVEMENT 这个前置开关 —— 很多人直接跑 SHRINK 报 ORA-10636，却不知道先去开它。
