SecureFiles 不可转 BasicFiles，因 Oracle 内核级禁止反向转换，报 ORA-43856 错误；唯一路径是重建表；BasicFiles 升级 SecureFiles 需满足 ASSM 表空间、兼容性 ≥11.2、无域索引、未启用并行 DML 四前提。
SecureFiles 转 BasicFiles 会失败，因为 Oracle 不允许反向转换
oracle 明确禁止将已启用 securefile 的 lob 段转回 basicfile —— 这不是权限或语法问题，是内核级限制。你执行 alter table ... modify lob (...) (store as basicfile) 时，会直接报错 ora-43853: securefile lobs cannot be created for non-assm tablespace 或更直白的 ora-43856: cannot convert securefile lob to basicfile lob。
常见错误现象：在迁移旧应用或试图“降级”存储策略时硬写转换语句，结果卡在 DDL 报错，甚至误以为是表空间没开 ASSM。
- 唯一可行路径是重建：导出数据 → 新建
BASICFILE表 → 导入 - 如果只是想节省空间，别碰转换，优先检查
COMPRESS、DEDUPLICATE和RETENTION参数是否合理启用 -
SECUREFILE表默认依赖自动段管理（ASSM）表空间；切到BASICFILE后反而可能因手工段管理（MSSM）引发碎片问题
BasicFiles 升级到 SecureFiles 需满足四个硬性前提
不是加个 STORE AS SECUREFILE 就能升级。Oracle 要求同时满足：表空间为 ASSM、数据库兼容性 ≥11.2、LOB 列未被索引（如 domain index）、且表未启用并行 DML（PARALLEL 属性为 DISABLE）。
典型翻车场景：DBA 在 12c 环境下对一张带 PARALLEL 4 的大表执行升级，DDL 看似成功，但后续插入 LOB 时触发 ORA-01735: invalid ALTER TABLE option 或静默退化回 BasicFiles。
- 先运行
SELECT tablespace_name, segment_space_management FROM dba_tablespaces WHERE tablespace_name = 'YOUR_TS';确认是AUTO - 用
SELECT degree FROM dba_tables WHERE table_name = 'YOUR_TABLE';查并行度，非1或DEFAULT就得先ALTER TABLE ... NOPARALLEL - 升级语句必须带完整子句：
ALTER TABLE t MODIFY LOB (c) (STORE AS SECUREFILE (COMPRESS HIGH DEDUPLICATE));，漏掉括号或参数可能导致部分特性不生效
SecureFiles 的 COMPRESS 和 DEDUPLICATE 不是“开就省”，要看数据模式
COMPRESS 对重复文本块有效，但对加密后或随机二进制（如 JPEG header 变化）几乎无压缩率；DEDUPLICATE 依赖完整 LOB 值比对，1KB 差异就会让两个 10MB 文件无法去重 —— 它不是文件系统级的块级去重。
真实代价：开启 DEDUPLICATE 后每次 INSERT/UPDATE LOB 都要全局哈希查重，高并发写入时可能卡在 lob index contention 等待事件上；COMPRESS 则增加 CPU 开销，尤其在 OLTP 场景下影响明显。
- 测试方法：用
DBMS_SPACE.SPACE_USAGE对比启用前后UNFORMATTED_BYTES和UNUSED_BYTES - 建议只在归档表、文档库等写少读多、内容高度重复的场景开
DEDUPLICATE - 若 LOB 平均大小
LOB 段空间回收不等于 DELETE 数据，必须显式 SHRINK
删掉含 LOB 的行，或用 TRUNCATE，都只释放表段空间；LOB 数据本身仍躺在 LOBINDEX 和 LOBSEGMENT 里，标记为可覆盖但不归还给表空间。磁盘占用不会下降，dba_segments 里的 bytes 不变。
唯一可靠回收方式是 ALTER TABLE ... MODIFY LOB (...) (SHRINK SPACE)，但它要求表启用行移动（ENABLE ROW MOVEMENT），且执行期间会持 SHARE 锁，阻塞 DML。
- 执行前务必确认：表无物化视图日志、无未提交事务、且
LOB列没被函数索引引用 - 大表慎用：一次 SHRINK 可能持续数小时，期间
v$session_longops显示LOB shrink进度 - 替代方案：分区表可逐个
ALTER TABLE ... TRUNCATE SUBPARTITION ... UPDATE GLOBAL INDEXES，粒度更可控
真正麻烦的是跨多个版本的数据生命周期管理 —— SecureFiles 的 retention 控制、undo 保留、flashback 归档三者叠加时，空间释放时机完全不可预测。别信“删了就没了”，得盯着 dba_lob_partitions 和 v$securefile_shrink 才算心里有数。
