DBMS_LOB.WRITEAPPEND比WRITE更常用，因其无需指定偏移量、自动追加末尾，适合拼接文本和流式写入；WRITE仅适用于需覆盖重写的场景。
必须先获取有效 lob 定位器再操作，跳过 insert + select for update 步骤会直接报 ora-22275；lob 不是普通字段，不能 insert into t (c) values ('xxx') 直接赋值，否则触发 ora-01461。
为什么 DBMS_LOB.WRITEAPPEND 比 WRITE 更常用
DBMS_LOB.WRITE 要求显式指定偏移量和长度，容易因计算错误覆盖已有内容或写入越界；DBMS_LOB.WRITEAPPEND 总是从末尾追加，无需维护当前长度，适合拼接文本、流式写入文件块等场景。
- 单次调用最多写 32767 字节（受
VARCHAR2/RAW长度上限限制），超长需循环分段调用 - 对 CLOB 写入中文时，确保传入的字符串字符集与数据库一致，否则可能截断或乱码
- 若需覆盖重写某一段（如修改 XML 中特定节点），才选
WRITE；日常填充推荐WRITEAPPEND
SecureFile 是 RAC 下 LOB 性能提升的关键开关
BasicFile 在 RAC 中实际是“伪共享”，各节点各自管理 LOB 缓存和锁，高并发下极易出现 gc current block 2-way 等等待；SecureFile 由 RAC-aware 引擎统一调度，压缩、去重、日志控制都在线且无锁。
- 建表必须显式指定
STORE AS SECUREFILE，不能依赖初始化参数db_securefile=PERMITTED的默认行为 - 搭配
DISABLE STORAGE IN ROW和CHUNK 8192（设为DB_BLOCK_SIZE整数倍），避免小块切分引发索引深度增加 -
PCTVERSION 15是 RAC 高并发更新的合理起点，防止旧版本 LOB 数据块堆积导致ORA-22924
从 BFILE 加载数据时 fileopen/fileclose 容易被忽略
用 DBMS_LOB.LOADFROMFILE 从操作系统文件读取数据，必须显式调用 DBMS_LOB.FILEOPEN 和 DBMS_LOB.FILECLOSE，否则句柄无效，操作静默失败或返回空内容。
- 未
FILEOPEN就调用LOADFROMFILE，不会报错但不写入任何数据 - 忘记
FILECLOSE可能导致操作系统句柄泄漏，后续调用报ORA-22285（non-existent directory or file） - 建议在
EXCEPTION块中补上FILECLOSE，确保异常路径也释放资源
真正卡住性能的往往不是单次写入逻辑，而是定位器生命周期管理、RAC 下的存储参数组合、以及 BFILE 句柄这种“看起来可选实则强制”的步骤——这些地方一漏，问题就藏得深，排查时容易绕远路。
