ORA-21560错误主因是DBMS_LOB.READ的amount超32767字节或offset=0（应≥1）；读CLOB需VARCHAR2(32767)、BLOB需RAW(32767)，且注意CLOB按字符、BLOB按字节计数。
DBMS_LOB.READ 读取大 CLOB/BLOB 时总报 ORA-21560
根本原因是 dbms_lob.read 的 amount 参数不能超过 32767 字节（pl/sql raw 或 varchar2 缓冲区上限），且起始位置 offset 从 1 开始、不能为 0——这点和很多语言习惯相反，错填 offset := 0 就直接报这个错。
实操建议：
- 用
DBMS_LOB.GETLENGTH先查真实长度，别信表定义里的CLOB就“无限” - 分块读：每次
amount设为LEAST(32767, remaining_length)，循环推进offset - 读 CLOB 时，目标变量必须是
VARCHAR2(32767)；读 BLOB 时，必须是RAW(32767)，类型不匹配也会触发 ORA-21560 - 注意字符集：CLOB 按字符计数，BLOB 按字节计数；UTF-8 下一个中文占 3 字节，但
GETLENGTH对 CLOB 返回的是字符数，别混着用
DBMS_LOB.WRITE_APPEND 往空 CLOB 写数据失败
空 CLOB（EMPTY_CLOB()）不是 NULL，但也没分配存储空间。直接对它调 WRITE_APPEND 会报 ORA-22285：non-existent directory or file for FILEEXISTS operation——错误信息极具误导性，实际和目录无关。
实操建议：
- 必须先用
DBMS_LOB.CREATETEMPORARY创建可写临时 LOB，或用SELECT ... FOR UPDATE锁定行后，对字段赋值EMPTY_CLOB()再WRITE - 常见误操作：在 INSERT 语句里直接写
VALUES ('xxx', EMPTY_CLOB())，然后想马上WRITE_APPEND——不行，得先 COMMIT 或至少执行一次SELECT ... FOR UPDATE -
WRITE_APPEND只追加，不支持覆盖；要重写整个内容，用WRITE+offset => 1
PL/SQL 中处理 >32KB 的 CLOB 字符串拼接
PL/SQL 的 VARCHAR2 最大 32767 字节，硬拼大会截断或报 ORA-06502。想把多个字符串合进一个 CLOB，不能靠 || 连接后再赋值。
实操建议：
- 用
DBMS_LOB.CREATETEMPORARY创建临时 CLOB，再用多次WRITE_APPEND累加 - 避免在循环里反复
SELECT ... INTO clob_var：每次 SELECT 都可能触发 LOB 定位开销，尤其远程 DB 链接下延迟明显 - 如果只是构造固定模板，优先用
UTL_RAW.CAST_TO_VARCHAR2处理 RAW，或改用XMLSERIALIZE等 SQL 层函数，绕过 PL/SQL 限制
DBMS_LOB.COPY 性能差、卡住或只复制前 4KB
COPY 不是内存拷贝，它本质是 SQL 引擎级的 LOB 段复制，会走 undo/redo，大对象复制时锁表时间长、日志暴增。更隐蔽的问题是：如果目标 LOB 是空的（EMPTY_CLOB()），且没提前 CREATETEMPORARY 或 FOR UPDATE，COPY 会静默失败——只写入开头 4KB 左右就停，无报错。
实操建议：
- 确认目标 LOB 已初始化：要么
SELECT ... FOR UPDATE后赋EMPTY_CLOB()，要么显式DBMS_LOB.CREATETEMPORARY - 跨表复制大 LOB，优先用
INSERT /*+ APPEND */ ... SELECT，让 Oracle 自动优化 LOB 存储路径 - 纯 PL/SQL 内复制，
amount别设太大（如 1MB），控制在 64–256KB 区间平衡内存与 IO 次数
LOB 操作真正难的不是语法，是搞清“当前这个 LOB 是临时的、持久的、空的、还是被其他会话锁着的”。多数报错表面是参数错，根子在 LOB 的生命周期状态没对齐。每次操作前，花 10 秒跑一遍 DBMS_LOB.GETLENGTH 和 DBMS_LOB.ISOPEN，比硬试三次更快。
