SECUREFILE LOB 在线收缩唯一方式是 ALTER TABLE MODIFY LOB 配合 SHRINK SPACE，且必须满足 LOB 为 SECUREFILE 类型、表空间启用 ASSM 两个前提；SHRINK SPACE CASCADE 会跳过 LOB 段，不释放其空间。
alter table modify lob 配合 shrink space 是唯一在线收缩 securefile lob 的方式，但必须满足前提且不能跨分区隐式生效。
SECUREFILE LOB 收缩必须单独执行，SHRINK SPACE CASCADE 会跳过它
你执行 ALTER TABLE t1 SHRINK SPACE CASCADE 后发现 LOB 段空间没变，不是命令写错了，是 Oracle 明确设计为“跳过 LOB”。哪怕表里只有一个 SECUREFILE LOB 列，它也不会被连带处理。
常见误判是查 DBA_SEGMENTS 看到 LOB 段大小不变，就以为整个 SHRINK 失败——其实只是 LOB 没动，普通表段可能已成功收缩。
收缩前必须确认 LOB 是 SECUREFILE 类型且所在表空间支持 ASSM
执行前先验证两件事，缺一不可：
- 查 DBA_LOBS：确认 segment_name 对应的 securefile 列值为 YES，且 tablespace_name 在 DBA_TABLESPACES 中 segment_space_management 为 AUTO
- BASICFILE LOB 完全不支持 SHRINK SPACE，19c 中强行执行会报 ORA-43852；若发现是 BASICFILE，只能重建（MOVE PARTITION + REBUILD INDEX），且需额外空间
- 表本身无需启用行移动（ENABLE ROW MOVEMENT 对 LOB 收缩无影响）
收缩命令语法和参数选择直接影响效果
ALTER TABLE t1 MODIFY LOB (lob_col) (SHRINK SPACE) 是标准写法，注意括号位置不能省略；可加 COMPACT 或不加：
- SHRINK SPACE COMPACT：只重组 LOB 数据块，不调 HWM，锁时间短，适合业务高峰期分步操作
- SHRINK SPACE（无后缀）：重组 + 调整 HWM，释放空间立竿见影，但需短暂独占锁，期间阻塞对该 LOB 列的读写
- 不支持 CASCADE，加了会报 ORA-30871
验证是否真收缩成功，别信 DBA_SEGMENTS 的 bytes 字段
DBA_SEGMENTS.bytes 更新有延迟，且 LOB 段可能被缓存；最可靠方法是对比收缩前后：
- 执行 SELECT segment_name, blocks FROM dba_segments WHERE segment_name = 'SYS_LOB00000XXXX$$'（LOB 段名在 DBA_LOBS.segment_name 中查）
- blocks 值变小才算成功；
- 若仍没变化，大概率是 LOB 数据实际碎片率低，或存在未提交事务/长时间打开的 LOB locator（查 V$LOB 和 V$SESSION_LONGOPS）
真正难的不是执行那条命令，而是判断该不该收缩、什么时候收缩、收缩后要不要立刻 resize 数据文件——这些没法靠一条 SQL 解决。
