应使用dbms_lob.write或dbms_lob.append替代字符串拼接赋值，因pl/sql中clob_var := clob_var || 'xxx'会为每次拼接创建新clob副本且旧副本不立即释放，导致uga内存溢出触发ora-04030或ora-20000。

直接用 dbms_lob.write 或 dbms_lob.append 替代拼接字符串赋值，否则存储过程会在 pl/sql 引擎内构建完整字符串副本，触发 ora-20000 / ora-04030 类内存溢出。

为什么存储过程里拼接 CLOB 会炸内存？

PL/SQL 中对 CLOB 变量做 clob_var := clob_var || 'xxx' 操作时，Oracle 会为每次拼接创建新 CLOB 副本（即使源 CLOB 是临时的），旧副本不会立即释放。几十次循环后，堆区积累大量未回收大对象，最终触发 ORA-04030: out of process memory 或 ORA-20000: ORU-10027: buffer overflow。

• 不是数据库 SGA 不够，是 PL/SQL 运行时堆（UGA）被撑爆
• DBMS_OUTPUT.PUT_LINE 输出大 CLOB 也会触发 ORA-10027，哪怕只输出一次
• 即使目标字段是 CLOB，UPDATE ... SET col = 'huge string' 仍会把整个字面量加载进 PGA

安全更新 CLOB 的三步写法（必须用 LOB API）

绕过字符串拼接，直接在数据库端操作 LOB 定位器：

• 先 SELECT col INTO l_clob FROM t WHERE ... FOR UPDATE 获取可修改的 LOB 定位器（注意加 FOR UPDATE）
• 用 DBMS_LOB.WRITE 写入新内容（覆盖）或 DBMS_LOB.APPEND 追加（需确保目标 CLOB 已初始化）
• 若需从长字符串构造 CLOB，用 DBMS_LOB.CREATETEMPORARY + DBMS_LOB.WRITE 分块写，别用 TO_CLOB('...') 直接转

示例片段：

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

DECLARE
  l_clob CLOB;
  l_buffer VARCHAR2(32767) := '...'; -- 单次最多 32KB
BEGIN
  SELECT content INTO l_clob FROM articles WHERE id = 123 FOR UPDATE;
  DBMS_LOB.WRITE(l_clob, LENGTH(l_buffer), 1, l_buffer);
  COMMIT;
END;

MyBatis/Java 调用存储过程时的配套避坑点

Java 层传入 CLOB 参数，如果存储过程内部再做字符串拼接，照样溢出：

• Java 侧不要用 setString() 传超长文本——改用 setClob(Reader) 或 setCharacterStream()
• 存储过程参数声明必须是 IN OUT CLOB，不能是 VARCHAR2（否则隐式转换触发全量加载）
• 调用前确认连接未启用 auto-commit，LOB 定位器依赖事务上下文
• MyBatis-Plus 的 @SelectKey 若涉及 CLOB 字段，需配 jdbcType=ORACLECURSOR 避免驱动误判类型

容易被忽略的底层约束

即使代码逻辑正确，以下环境因素仍会导致 LOB 操作失败：

• Oracle 11g 及更早版本不支持 DBMS_LOB.WRITEAPPEND，必须用 WRITE + GETLENGTH 手动算偏移
• DBMS_LOB.APPEND 要求目标 CLOB 已存在且非 NULL；首次写入必须用 WRITE 或先 DBMS_LOB.CREATETEMPORARY
• 存储过程所在用户需显式授予 EXECUTE ON DBMS_LOB 权限（默认不包含）
• RAC 环境下，LOB 定位器跨实例无效，FOR UPDATE 必须在同实例执行

真正卡住人的往往不是语法，而是 LOB 定位器生命周期和权限链路断在了某个环节。