临时LOB会撑爆TEMP表空间，因其按会话生命周期持有且不自动释放，需显式调用DBMS_LOB.FREETEMPORARY；高并发下未释放的LOB持续占用TEMP块，导致空间飙升。
临时LOB为什么会撑爆TEMP表空间
临时LOB（LOB类型在未显式指定持久化时的内存/磁盘行为）不是“用完即删”，而是按会话生命周期持有：只要会话没断开、LOB变量没被DBMS_LOB.FREETEMPORARY释放，它就一直占着TEMP里的块。高并发下大量会话同时创建CLOB/BLOB做XML解析、JSON拼装或大文本处理，每个会话可能持几百MB，v$tempseg_usage里SEGTYPE = 'LOB_DATA'持续不降，TEMP瞬间飙到95%+。
必须显式调用 DBMS_LOB.FREETEMPORARY
Oracle不会自动回收临时LOB占用的空间，哪怕你把LOB变量设为NULL或离开PL/SQL块作用域。不手动释放，空间就卡在TEMP里，直到会话结束——而应用连接池里的会话往往长连接复用，一卡就是几小时。
- 释放前必须确认该LOB不再被任何SQL或函数引用（比如没传给
UTL_HTTP或XMLTYPE构造函数） - 释放后再次访问该LOB变量会报
ORA-22275: invalid LOB locator specified，所以释放时机要放在所有读写操作之后 - 示例：
DECLARE l_clob CLOB; BEGIN DBMS_LOB.CREATETEMPORARY(l_clob, TRUE); -- ... 处理逻辑，如 DBMS_LOB.WRITEAPPEND DBMS_LOB.FREETEMPORARY(l_clob); -- ✅ 必须加这行 END;
V$TEMPORARY_LOBS 是定位泄漏的关键视图
光看v$sort_usage只能看到SORT和HASH，漏掉真正的元凶。查V$TEMPORARY_LOBS才能揪出谁在狂建临时LOB：
-
TOTAL_LOBS高 +TEMP_BLOCKS持续增长 → 某个会话正在累积未释放LOB -
CACHE_LOBS远高于NOCACHE_LOBS→ LOB被缓存在buffer cache，但没被释放，既吃TEMP又吃SGA - 关联
v$session查MACHINE和PROGRAM，快速锁定是哪个应用模块（比如jdbc thin client或oracle@web01 (J000)）
常用诊断语句：
SELECT s.sid, s.serial#, s.machine, s.program, t.total_lobS, t.temp_blocks/1024/1024 AS mb FROM v$temporary_lobs t, v$session s WHERE t.sid = s.sid ORDER BY t.temp_blocks DESC;
避免在循环中反复创建临时LOB
常见反模式：在一个FOR循环里对每条记录都CREATETEMPORARY + FREETEMPORARY。看似安全，但每次创建都会触发TEMP分配新extent，碎片多、性能差；更糟的是，如果某次异常跳过FREETEMPORARY，就直接泄漏。
- 改用单个LOB变量复用：
DBMS_LOB.TRIM(l_clob, 0)清空内容，比反复创建销毁更轻量 - 对纯内存操作（如小文本拼接），优先用
VARCHAR2(32767)替代CLOB，绕过TEMP - 批量处理时，用
DBMS_LOB.LOADFROMFILE或直接绑定LOB参数，减少中间临时对象
真正难处理的从来不是TEMP文件大小，而是那些“活着却不干活”的临时LOB——它们安静地躺在V$TEMPORARY_LOBS里，等你凌晨三点翻日志时才突然现身。
