lob空间失控主因是basicfile的in_row与pctversion机制导致双重占用和旧版本堆积；迁移至securefiles需停写move，且须用dbms_space.space_usage查真实占用，chunk仅对新写生效。

lob段空间爆满时，dba_segments里看到的不是表，而是sys_lob*段

lob数据不存于表段内，而是在独立段中管理。一旦select * from dba_segments where segment_name like 'sys_lob%' and bytes > 1073741824返回大量gb级段，说明lob空间失控了——这时候查原表行数可能才几万，但sys_lob段已占上百gb。

根本原因在于：BasicFile LOB默认启用ENABLE STORAGE IN ROW，小LOB（≤3964字节）会挤进表块，大LOB才进单独段；但只要发生过一次UPDATE，哪怕只改了个字段，Oracle就可能把原本在行内的LOB“踢出去”变成NOINROW，且不会自动回收原行内空间，导致双重占用。

• 用SELECT COLUMN_NAME, IN_ROW, CHUNK, PCTVERSION FROM DBA_LOBS WHERE TABLE_NAME = 'YOUR_TABLE'确认当前策略
• BasicFile下IN_ROW=NO且PCTVERSION设得过高（如默认10），长期更新会产生大量旧版本LOB块，无法被常规DELETE清理
• SecureFiles默认禁用IN ROW、不维护PCTVERSION，版本由RETENTION策略统一控制，更可控

从BasicFile迁移到SecureFiles必须停写，且ALTER TABLE ... MOVE LOB会锁全表

很多人以为加个USING SECUREFILE就能在线切换，实际ALTER TABLE t MODIFY LOB(c) (SECUREFILE)在12c之前根本不支持，12c+也仅限新插入LOB生效，存量数据仍走BasicFile路径。

真正迁移只能靠MOVE，但这个操作会持有SS（sub-share）锁，阻塞所有DML。如果LOB列有索引，还得重建索引——而ALTER INDEX ... REBUILD ONLINE对LOB索引无效，必须离线重建。

• 执行前务必检查：SELECT * FROM V$SESSION WHERE EVENT LIKE 'enq: TX - row lock contention'，避免在业务高峰跑
• ALTER TABLE t MOVE LOB(c) STORE AS SECUREFILE (COMPRESS HIGH DEDUPLICATE)中，COMPRESS和DEDUPLICATE会显著延长MOVE时间，测试环境先压测
• MOVE后原BasicFile段不会自动删除，需手动DROP SEGMENT或等ASSM自动回收，但前提是没开启DELAYED_SEGMENT_CREATION=FALSE

DBMS_SPACE.SPACE_USAGE查SecureFiles真实空间，别信DBA_SEGMENTS.BYTES

DBA_SEGMENTS.BYTES显示的是分配空间，SecureFiles大量使用压缩和去重后，实际占用可能只有1/10。直接按这个值扩容，容易买多几十TB存储还解决不了问题。

DBMS_SPACE.SPACE_USAGE能穿透压缩层，返回UNFORMATTED_BYTES（未格式化）、UNUSED_BYTES（已分配但未用）、USED_BYTES（真正写入数据）。注意它只对SecureFiles有效，BasicFile调用会报ORA-40439。

• 调用前必须EXEC DBMS_SPACE.CREATE_SECFILE_OBJECT('YOUR_SCHEMA', 'YOUR_TABLE', 'YOUR_LOB_COLUMN')注册对象
• 结果中USED_BYTES接近UNUSED_BYTES？说明压缩率低或数据本身不可压缩（如加密二进制流）
• 如果UNFORMATTED_BYTES持续增长，可能是RETENTION设得太长，旧版本LOB堆积，需调低RETENTION 3600（秒）

BasicFile的CHUNK大小改不了，SecureFiles的CHUNK影响随机读性能

BasicFile建表时指定的CHUNK（默认8K）是硬编码在段头里的，后续ALTER TABLE无法修改。而SecureFiles的CHUNK虽可改，但只对新写入生效——老块仍按旧CHUNK组织，混合CHUNK会导致读取时频繁跨块寻址。

尤其当应用频繁读取固定偏移的LOB片段（如视频流切片），CHUNK太小（如2K）会放大I/O次数；太大（如64K）又浪费内存缓冲区。实测Web内容场景，16K是较平衡值。

• 查当前CHUNK：SELECT CHUNK FROM DBA_LOBS WHERE TABLE_NAME='T' AND COLUMN_NAME='C'
• SecureFiles迁移后想调CHUNK，只能MOVE并显式指定CHUNK 16384，没有在线调整方式
• BasicFile下CHUNK和DB_BLOCK_SIZE强绑定，若块大小是16K，CHUNK却设8K，会强制拆成两个物理块存，徒增I/O

LOB空间管理最麻烦的从来不是技术选项，而是业务逻辑里那些“顺手UPDATE整个LOB字段”的写法——SecureFiles再好，也救不了每秒覆盖写10MB PDF的接口。得先揪出这些代码，再谈存储选型。