Oracle 11g中LOB段不支持SHRINK SPACE，因不满足ASSM管理、行移动与HWM下移前提；唯一可行方式是ALTER TABLE MODIFY LOB(col)(SHRINK SPACE)，且需启用ROW MOVEMENT、确保表空间为AUTO、LOB为BASICFILE且compression=NONE。
ALTER TABLE ... SHRINK SPACE 在含 CLOB 的表上直接执行会失败，根本原因不是 CLOB 本身，而是段空间管理方式与 LOB 存储分离导致的 HWM（高水位）不一致。必须分步处理：先收缩主表段，再单独收缩 LOB 段，且两步都需满足 ASSM + SECUREFILE + 表启用行移动。
确认表和LOB段是否支持SHRINK
不是所有表都能 shrink。关键检查点有三个：
-
SELECT table_name, row_movement, monitoring FROM user_tables WHERE table_name = 'YOUR_TABLE';——ROW_MOVEMENT必须为ENABLED，否则SHRINK SPACE报ORA-10636: row movement is not enabled -
SELECT segment_name, segment_type, tablespace_name FROM user_segments WHERE segment_name IN (SELECT segment_name FROM user_lobs WHERE table_name = 'YOUR_TABLE');—— 确认 LOB 段存在，且所在表空间是ASSM（自动段空间管理），DICTIONARY管理的表空间不支持 shrink -
SELECT column_name, segment_name, securefile FROM user_lobs WHERE table_name = 'YOUR_TABLE';——SECUREFILE列应为YES；BASICFILELOB 不支持SHRINK SPACE，强行执行会报ORA-10635: Invalid segment or tablespace type
分两步执行收缩：主表段 + LOB段
不能只 shrink 表，CLOB 数据实际存于独立 LOB 段中，主表 shrink 后 LOB 段仍占大量空间。必须显式指定 LOB 列名：
ALTER TABLE your_table ENABLE ROW MOVEMENT; ALTER TABLE your_table SHRINK SPACE COMPACT; -- 先 compact 再 shrink，减少锁时间 ALTER TABLE your_table SHRINK SPACE;
接着收缩 LOB 段（注意：必须用 LOB (col_name) 语法，不能只写 LOB 段名）：
ALTER TABLE your_table MODIFY LOB (clob_col) (SHRINK SPACE);
- 如果 LOB 列是
DISABLE STORAGE IN ROW，shrink 效果更明显；默认ENABLE STORAGE IN ROW时，小 CLOB（≤3964 字节）存在行内，shrink 可能无感 - 若报
ORA-10637: Cannot shrink a LOB segment that is not in an ASSM tablespace，说明 LOB 段所在表空间不是 ASSM，需迁移：先ALTER TABLE your_table MOVE LOB(clob_col) STORE AS SECUREFILE (TABLESPACE new_assm_ts) -
SHRINK SPACE是 DML 操作，会触发完整事务日志，生产环境建议在低峰期执行，并确保有足够回滚空间
批量处理多张含CLOB的表
手动逐个写 ALTER TABLE 不现实。可用动态 SQL 构建脚本，但必须加安全校验：
SELECT 'ALTER TABLE ' || table_name || ' ENABLE ROW MOVEMENT;' FROM user_tables t WHERE EXISTS ( SELECT 1 FROM user_lobs l WHERE l.table_name = t.table_name AND l.securefile = 'YES' ) AND t.row_movement = 'DISABLED';
真正批量 shrink 的核心逻辑是：
SELECT 'ALTER TABLE ' || t.table_name || ' SHRINK SPACE;' ||
' ALTER TABLE ' || t.table_name || ' MODIFY LOB (' || l.column_name || ') (SHRINK SPACE);'
FROM user_tables t
JOIN user_lobs l ON t.table_name = l.table_name
WHERE t.row_movement = 'ENABLED'
AND l.securefile = 'YES'
AND t.tablespace_name IN (SELECT tablespace_name FROM dba_tablespaces WHERE segment_space_management = 'AUTO');
- 执行前务必对目标表做
ANALYZE TABLE ... VALIDATE STRUCTURE CASCADE，避免因数据块损坏导致 shrink 中断后无法回退 - 不要在脚本里加
EXECUTE IMMEDIATE自动执行——shrink 不可逆，出错可能丢数据；生成语句后人工 review 再执行 - 监控进度用：
SELECT * FROM v$session_longops WHERE opname LIKE 'shrink%';
为什么有时候SHRINK没效果？
常见假阴性场景：
- CLOB 数据被频繁更新但未真正删除（比如 UPDATE SET clob_col = clob_col || 'new'），旧版本仍保留在 UNDO/LOB 段中，shrink 前需
ALTER SYSTEM FLUSH SHARED_POOL并等待V$LOBSTAT中UNEXPIRED项归零 - 表上有未提交的长时间事务，
SHRINK会等待或报ORA-10631；查V$TRANSACTION和V$SESSION确认无长事务 - 使用了
LOGGING模式 shrink，重做量极大，看起来“卡住”，其实是在刷日志；可临时改NOLOGGING（但需承担备份失效风险） - 表空间剩余空间不足 shrink 后的最小尺寸（即 HWM 下方空闲空间太小），此时需先
ALTER DATABASE DATAFILE ... RESIZE缩小数据文件，再 shrink 段
最易被忽略的一点：SHRINK SPACE 不会降低数据文件物理大小，它只重排段内块、降低 HWM；要释放磁盘空间，还得配合 ALTER DATABASE DATAFILE ... RESIZE，而该命令的下限就是 HWM 值——所以必须先 shrink 段，再查 DBA_DATA_FILES 和 DBA_EXTENTS 算出可 resize 的最小值，否则直接 resize 会报 ORA-03297。
