SecureFiles是默认且推荐的LOB存储方式，BasicFiles仅在兼容性或许可限制下被动使用；DB_SECUREFILE参数控制策略：NEVER强制BasicFiles，PREFERRED（默认）优先SecureFiles但退化容错，ALWAYS要求ASSM表空间，FORCE无视BASICFILE声明但不推荐。
SecureFiles 是默认且推荐的选择，BasicFiles 仅应在明确兼容性或许可限制下被动使用。
DB_SECUREFILE 参数决定默认行为
Oracle 12c 起默认启用 DB_SECUREFILE=PERMITTED，但实际是否创建 SecureFiles 取决于表定义和该参数值。它不是“开关”，而是策略控制器：
-
NEVER：所有SECUREFILE关键字被忽略，强制走 BasicFiles；COMPRESS/ENCRYPT等子句直接报错ORA-40439 -
PREFERRED（默认）：未显式写BASICFILE时，优先尝试 SecureFiles；若表空间非 ASSM 或段未启用自动段管理，则退化为 BasicFiles -
ALWAYS：只要表空间是 ASSM，就强制 SecureFiles；但BASICFILE显式声明会被拒绝，报错ORA-40441 -
FORCE：连BASICFILE声明都无视——不推荐，可能破坏应用预期
运行时可通过 ALTER SYSTEM SET DB_SECUREFILE = 'PREFERRED' 动态调整，无需重启。
SecureFiles 功能依赖额外许可证
压缩、重复数据删除、透明加密这些功能不是开箱即用的：
-
COMPRESS和DEDUPLICATE需要 Oracle Advanced Compression 许可 -
ENCRYPT需要 Oracle Advanced Security 许可 - 没对应许可时，建表若带这些子句会报
ORA-40450或ORA-40451 - BasicFiles 完全不检查这些许可，所以旧系统迁移时容易因许可缺失导致建表失败
验证方式：SELECT * FROM v$option WHERE parameter LIKE '%Compression%' OR parameter LIKE '%Security%';
BasicFiles 仍存在的真实场景
不是“过时就该淘汰”，而是某些约束下不得不选：
- Oracle 11g R1 或更早版本 —— SecureFiles 尚未引入
- 表空间为手动段管理（MSSM），而
DB_SECUREFILE=ALWAYS会拒绝建表 - 应用代码硬编码依赖 BasicFiles 的 LOB locator 行为（例如某些 OCI 直接操作逻辑）
- 需要与 Oracle Streams 集成 —— SecureFiles 的重复数据删除不被支持，必须用 BasicFiles
- LOB 列已存在且量级极大，又无法停机做在线重定义（
DBMS_REDEFINITION）
注意：EMPTY_BLOB() / EMPTY_CLOB() 在两者中行为一致，但 DBMS_LOB.LOADFROMFILE 对 BasicFiles 的 chunk 大小敏感，SecureFiles 更宽容。
迁移不是 ALTER TABLE 一条命令能解决的
把现有 BasicFiles 表改成 SecureFiles，不能只改 DDL：
-
ALTER TABLE ... MODIFY LOB (...) (SECUREFILE)会报错ORA-40442—— 不支持原地升级 - 正确路径是在线重定义（
DBMS_REDEFINITION）或使用 SecureFiles Migration Utility - Migration Utility 要求额外等量磁盘空间，且全局索引需重建；若 LOB 分区多，耗时显著
- 迁移后务必验证：查询
USER_LOBS视图，确认SECUREFILE列值为YES，而非NO
最易被忽略的一点：即使迁移完成，旧的 BasicFiles 段不会自动清理，需手动 DROP SEGMENT 或等自动段清理（ASSM 下通常延迟发生）。
