LOB段须与LOB索引同表空间是Oracle硬性限制，因索引嵌入chunk地址映射逻辑，跨表空间会导致locator无法解析物理块；ENABLE STORAGE IN ROW仅对≤3964字节LOB生效，超限即外置；MOVE LOB前须检查行锁、延迟段创建及真实空间占用。
lob段单独放在外部表空间，不是为了“隔离数据”，而是为了解耦io压力和空间管理——尤其当表高频更新、lob访问模式又高度随机时，混在主表表空间里容易拖垮buffer cache命中率和写入吞吐。
为什么LOB段必须和LOB索引在同一个表空间
Oracle内部强制要求LOBSEGMENT和LOBINDEX共存于同一表空间，这是硬性限制，不是建议。尝试用ALTER TABLE ... MOVE LOB指定不同表空间会报错ORA-14642（表空间不匹配）。原因在于LOB索引结构直接嵌入chunk地址映射逻辑，跨表空间会导致定位器（locator）无法解析物理块位置。
-
DBA_LOBS.INDEX_NAME和SEGMENT_NAME始终成对出现，查USER_SEGMENTS能看到两者TABLESPACE_NAME完全一致 - 即使建表时只显式指定
LOB ... STORE AS (TABLESPACE ts1)，系统也会自动把索引也落到ts1，不会去主表表空间找 - 迁移LOB到新表空间时，必须同时MOVE segment和重建索引（
ALTER INDEX ... REBUILD），且不能加ONLINE——LOB索引不支持在线重建
Enable Storage In Row的实际生效边界
ENABLE STORAGE IN ROW不是“开关”，而是一个有严格字节阈值的策略：只有LOB值≤3964字节（含20字节locator + 16字节inode开销）才真正在行内；超了就立刻外置，且一旦发生UPDATE，哪怕只改了其他字段，原行内LOB也可能被“踢出”并残留空间。
- 新建表默认启用该选项，但
SELECT COLUMN_NAME, IN_ROW FROM DBA_LOBS WHERE TABLE_NAME = 'YOUR_TABLE'返回NO，说明已有数据触发过外置逻辑 - 修改已存在表的
IN_ROW属性不可直接ALTER，只能通过ALTER TABLE ... MOVE LOB重写整列，期间锁全表 - 小LOB（如JSON配置文本）设为
ENABLE能减少单次查询的IO次数；但若该列频繁UPDATE，反而因版本堆积导致PCTVERSION空间失控
停写MOVE时最易忽略的三个检查点
执行ALTER TABLE t MOVE LOB(c) STORE AS SECUREFILE前，不验证这三项，大概率在业务高峰卡死：
- 查
V$SESSION中是否存在enq: TX - row lock contention等待事件——说明当前有未提交事务正操作该表，MOVE会无限等待 - 确认
DELAYED_SEGMENT_CREATION=FALSE，否则MOVE后旧BasicFile段不会立即释放，需手动DROP SEGMENT或等ASSM后台回收 - 用
DBMS_SPACE.SPACE_USAGE而非DBA_SEGMENTS.BYTES评估SecureFiles真实占用——压缩+去重后USED_BYTES可能只有分配空间的1/8，按BYTES扩容会买多几十TB
真正麻烦的从来不是MOVE命令本身，而是MOVE之后那些没被清理的旧LOB段，以及误信DBA_SEGMENTS里的数字去申请存储配额。
