securefiles lob 无法通过 shrink space 回收空间，必须使用 alter table ... move lob ... store as securefile 才能真正降低 hwm 并释放物理空间。
SecureFiles LOB 无法用 SHRINK SPACE 回收空间
直接对含 SecureFiles LOB 的表执行 ALTER TABLE ... SHRINK SPACE，表段高水位（HWM）可能下降，但 LOB 段的 HWM 完全不受影响——空间一丁点都不会释放。这是 Oracle 的硬限制，不是操作失误。原因在于 SecureFiles 的存储引擎不支持段级 shrink，它的空间管理依赖于内部 chunk 分配和版本清理机制，而非传统数据块重排。
常见错误现象：SHRINK SPACE COMPACT 成功返回，DBA_SEGMENTS.BYTES 却纹丝不动；V$LOBSTAT 显示 SPACE_USED 和 SPACE_ALLOCATED 差值极大，说明大量空间被“悬空”占用。
- 必须先确认 LOB 类型：
SELECT securefile FROM dba_lobs WHERE table_name = 'YOUR_TABLE' AND column_name = 'YOUR_LOB_COL'，结果为YES才是 SecureFile - BasicFile LOB 可以用
SHRINK SPACE或MOVE降低 HWM，但 SecureFile 不行 - 强行对 SecureFile LOB 执行
SHRINK SPACE不报错，但无效；19c 中对 BASICFILE 执行会报ORA-43852
SecureFiles LOB 空间回收唯一可靠路径：MOVE LOB
ALTER TABLE ... MOVE LOB (...) STORE AS SECUREFILE 是唯一能真正降低 SecureFiles LOB 高水位、释放物理空间的操作。它会重建整个 LOB 段，丢弃所有已删除或过期版本的数据块，只保留当前活跃内容。
关键细节：
- 语法必须显式指定
STORE AS SECUREFILE，哪怕原就是 SecureFile，否则会退化为 BasicFile - 推荐加
(COMPRESS HIGH)或(DEDUPLICATE)，在移动过程中同步压缩/去重，进一步节省空间 - 执行期间表可读写，但该 LOB 列的 DML 会被短暂阻塞（秒级），非 LOB 列索引不会失效
- 执行后务必验证：
SELECT segment_name, bytes/1024/1024 FROM dba_segments WHERE segment_name IN (SELECT segment_name FROM dba_lobs WHERE table_name = 'YOUR_TABLE')，对比移动前后数值
BasicFiles LOB 空间回收：MOVE 或 SHRINK SPACE 均可，但有区别
BasicFiles 对 SHRINK SPACE 支持完整，执行后表段 + LOB 段 HWM 都会下降。但要注意：它不压缩、不去重、不清理旧版本——只是把现有数据块紧凑排列。
MOVE 更彻底，会重建整个 LOB 段，也能释放空间，但代价更高：
-
MOVE会令所有非 LOB 列上的索引变为UNUSABLE，必须手动ALTER INDEX ... REBUILD ONLINE -
MOVE需要额外临时空间（≈原 LOB 段大小），而SHRINK SPACE只需少量排序区 - 如果表启用了行移动（
ENABLE ROW MOVEMENT），SHRINK SPACE才可用；BasicFiles 本身不要求这个
生产环境优先选 SHRINK SPACE，除非你明确需要 MOVE 带来的结构重排或表空间迁移效果。
迁移前必须查清三件事，漏一项就白干
不管是 SecureFiles 还是 BasicFiles，空间回收失败最常见的原因是前置检查没做全：
- 表空间是否启用 ASSM？查
SELECT segment_space_management FROM dba_tablespaces WHERE tablespace_name = 'YOUR_TS'，必须是AUTO；MSSM 表空间下 SecureFilesMOVE LOB会报错 - 用户是否有
ALTER ANY TABLE权限？MOVE LOB是 DDL，不是普通 DML 权限能覆盖的 - LOB 数据是否真被删了？
DELETE只标记删除，不释放空间；必须已COMMIT，且未开启保留策略（PCTVERSION或RETENTION过大）锁住旧版本
最易被忽略的是第三点：应用逻辑里 DELETE 后没 COMMIT，或者 DBA 误设了 RETENTION MIN 86400，导致旧版本全被钉住——这时无论怎么 MOVE 或 SHRINK，空间都收不回来。
