Oracle 11g中ALTER TABLE...SHRINK SPACE是唯一原生支持在线降低HWM的标准方法，分COMPACT（允许DML）和SHRINK SPACE（短暂锁表）两阶段，需启用ROW MOVEMENT、ASSM表空间，并对LOB加CASCADE。
SHRINK SPACE 是唯一能在线降低 HWM 的标准方法
Oracle 11g 中，ALTER TABLE ... SHRINK SPACE 是唯一原生支持「不锁表完成 HWM 下降」的操作。它分两阶段执行：先 SHRINK SPACE COMPACT（仅移动行、不调整 HWM，全程允许 DML），再 SHRINK SPACE（真正回收空间、重置 HWM，此时需短暂锁表，通常毫秒级）。关键前提是表必须启用行移动：ALTER TABLE table_name ENABLE ROW MOVEMENT。
常见错误现象：直接执行 SHRINK SPACE 报错 ORA-10636: row movement is not enabled；或未做 COMPACT 就直接收缩，导致高并发下 UNDO 暴涨甚至事务失败。
- 必须确认表空间为 ASSM（自动段空间管理）：
SELECT segment_space_management FROM dba_tablespaces WHERE tablespace_name = 'YOUR_TS'，返回AUTO才能用 SHRINK - LOB 字段需显式加
CASCADE：如含CLOB或BLOB，必须写SHRINK SPACE CASCADE，否则 LOB 段 HWM 不变 - 分区表可按分区收缩：例如
ALTER TABLE t SHRINK SPACE PARTITION p_01，避免整表阻塞
MOVE 操作不能“不锁表”，别被误导
ALTER TABLE ... MOVE 在 Oracle 11g 中全程锁表（DML 阻塞），不是在线操作。它适合维护窗口明确、能接受短时业务中断的场景。有人误以为加 ONLINE 参数就能在线——但该参数在 11g 中不支持表 MOVE，仅从 12c R2 起才引入 ONLINE 子句（且仍有限制）。
容易踩的坑：
- MOVE 后所有索引状态变为
UNUSABLE，必须立即重建，否则后续查询走全表扫描或报错ORA-01502 - 未处理 LOB 字段会直接报错
ORA-22858: invalid alteration of datatype，必须显式指定LOB (col_name) STORE AS (TABLESPACE ts_name) - MOVE 不改变统计信息，必须手动执行
DBMS_STATS.GATHER_TABLE_STATS，否则优化器可能选错执行计划
为什么 TRUNCATE + INSERT 不是“安全在线”方案
看似能重置 HWM，但 TRUNCATE 是 DDL，会隐式提交并获取 DML 级排他锁（非仅 DDL 锁），期间所有 INSERT/UPDATE/DELETE 都被阻塞。更危险的是：若中间出错（如 INSERT 失败、网络中断），数据已丢失无法回滚。
真实使用场景极少适用：
- 仅当表无外键引用、无触发器、且能接受数分钟以上不可写时才考虑
- 必须提前禁用约束、关闭触发器，并确保临时表与原表结构完全一致（包括默认值、虚拟列、隐藏列）
- 即使成功，也会产生巨量 REDO 和归档压力，对主备同步链路造成冲击
最容易被忽略的细节：COMPACT 阶段也影响性能
很多人只关注最终 SHRINK SPACE 的锁表时间，却忽视 SHRINK SPACE COMPACT 阶段的副作用：它本质是批量 INSERT /*+ APPEND */ + DELETE，会生成大量 UNDO 和 REDO，尤其在高更新频率的表上，可能拖慢其他事务、触发 UNDO 表空间告警，甚至导致归档日志写满。
建议做法：
- 避开业务高峰执行
COMPACT，观察V$TRANSACTION和V$UNDOSTAT中的 UNDO 消耗 - 对超大表（>10GB），先用
SHRINK SPACE COMPACT分批压紧，再择机执行最终SHRINK SPACE - 收缩后务必检查索引状态：
SELECT index_name, status FROM user_indexes WHERE table_name = 'T'，VALID才算真正完成
