存储过程不能接收原始lob值作参数，因为oracle采用定位器语义：clob/blob参数实际传递的是指向数据的轻量级指针，而非数据本身；若误用varchar2/raw类型会导致截断或ora-06502错误。
不能直接把 clob/blob 值作为 in 参数传给存储过程，必须用 lob 定位器（locator）——也就是变量类型为 clob 或 blob 的参数，它本质是数据库内部指针，不是数据本身。
为什么存储过程不能接收原始 LOB 值作参数
Oracle 在 PL/SQL 中对 LOB 的处理遵循「定位器语义」：SELECT 查询返回的不是 LOB 数据，而是指向数据的定位器；函数/过程参数若声明为 CLOB，实际传入的就是这个定位器。试图用 IN VARCHAR2 接收超长文本、或用 IN RAW 接收二进制块，会在运行时报 ORA-06502: PL/SQL: numeric or value error 或截断（仅前 32767 字节可能被隐式转换）。
常见错误现象：
- 调用含
IN VARCHAR2参数的过程插入 40KB 文本 → 只存入前 32767 字节，无报错但数据丢失 - 过程内对参数做
DBMS_LOB.GETLENGTH()返回NULL或0→ 实际传入的是空字符串而非空 LOB 定位器 - 在包头声明
PROCEDURE p(p_clob IN CLOB)，但调用时写成p('hello' || largetext)→ 编译失败：PLS-00306: wrong number or types of arguments
正确声明和调用含 LOB 定位器的存储过程
参数类型必须显式声明为 CLOB / BLOB，且调用方需确保传入的是数据库中已存在的 LOB 列值或临时 LOB。
实操建议：
- 存储过程定义中，使用
IN CLOB或IN OUT CLOB，禁止用IN VARCHAR2替代 - 调用时，只能传表中某行的 LOB 字段（如
SELECT my_clob FROM t WHERE id = 1），或先用DBMS_LOB.CREATETEMPORARY()创建临时 LOB 再传入 - 若从应用层（如 Python cx_Oracle）调用，需绑定参数类型为
cx_Oracle.CLOB或cx_Oracle.BLOB，不能用字符串直传 - 不要在过程内对
IN CLOB参数调用DBMS_LOB.WRITE()—— 这会报ORA-22275: invalid LOB locator specified，因为IN参数不可写；需改为IN OUT并确保调用前已锁定源行（FOR UPDATE）
示例（合法调用）：
DECLARE l_clob CLOB; BEGIN SELECT content INTO l_clob FROM docs WHERE id = 100 FOR UPDATE; process_doc(l_clob); -- 此处 l_clob 是有效定位器 END;
传递过程中容易忽略的事务与锁定问题
LOB 定位器不是独立对象，它依赖于所在行的事务上下文。若在未加锁的 SELECT 后直接传入定位器，后续在过程内读写时可能遇到 ORA-22285: non-existent directory or file for FILEOPEN operation（BFILE）或更常见的 ORA-22275（内部 LOB）。
关键约束：
-
SELECT ... INTO获取定位器后，必须在同一事务中完成所有DBMS_LOB操作；跨事务或会话传递定位器无效 - 对内部 LOB（CLOB/BLOB）执行写操作前，必须用
SELECT ... FOR UPDATE锁定该行，否则DBMS_LOB.WRITE会失败 - BFILE 定位器虽可跨事务传递，但所指向的 OS 文件路径必须存在且 Oracle 用户有读权限，且
DIRECTORY对象已创建并授权 - 临时 LOB（
DBMS_LOB.CREATETEMPORARY创建）只在当前会话生命周期内有效，不可用于跨过程持久化
性能陷阱：定位器传递不等于数据拷贝
传入 CLOB 参数本身几乎零开销——只是传一个轻量级指针。但后续调用 DBMS_LOB.SUBSTR、DBMS_LOB.READ 等函数时，实际触发磁盘 I/O 或缓存访问，性能取决于 LOB 数据是否在行内（ENABLE STORAGE IN ROW，以及是否做了分区或压缩。
注意点：
- 避免在循环中反复调用
DBMS_LOB.GETLENGTH()—— 它每次都会访问数据段，可缓存一次结果复用 - 用
DBMS_LOB.SUBSTR(clob, 32767, 1)读全文时，若 LOB > 32KB，会静默截断；应改用DBMS_LOB.READ分块读取 - 过程内新建临时 LOB（
CREATETEMPORARY）后未调用FREETEMPORARY，会导致 PGA 内存泄漏，尤其在高并发场景下 - 不要在 SQL 层（如视图、函数索引表达式）里频繁调用
DBMS_LOB函数 —— 它们无法向量化，会严重拖慢查询
真正难处理的从来不是“怎么传”，而是“传完之后在哪一环节触发了隐式读、是否持有锁、数据到底落在哪块存储上”。定位器本身很薄，背后的存储结构和事务边界才是复杂度所在。
