ORA-01652真因是CLOB参与隐式排序操作（如ORDER BY、GROUP BY、物化视图刷新等）导致临时表空间溢出，而非CLOB本身过大；关键优化是为物化视图日志表建复合索引并避免未提交的LOB事务。
ORA-01652 报错真因不是 CLOB 本身，而是隐式排序操作
CLOB 字段传入存储过程中不直接消耗临时表空间，但一旦参与 ORDER BY、GROUP BY、DISTINCT、UNION 或物化视图刷新等场景，Oracle 就会尝试对 CLOB 值做比较或排序——而 CLOB 无法在内存中完整排序，必须 spill 到临时表空间。此时报 ORA-01652，本质是排序路径没绕开大对象，不是“CLOB 太大”，而是“不该排却排了”。
物化视图刷新 + CLOB 是最典型的隐式 WINDOW SORT 触发点
当物化视图日志表（如 MLOG$_MV_XXX）含 CLOB 字段，且刷新使用默认快速刷新路径时，Oracle 会按 SNAPTIME$$ 全表扫描后做窗口排序合并，这个 WINDOW SORT 不走索引，直接压爆 TEMP。
- 查当前刷新是否走该路径：
SELECT * FROM V$MVREFRESH看STATE和SQL_TEXT - 关键优化不是调
PGA_AGGREGATE_TARGET，而是建复合索引：CREATE INDEX idx_mlog_snap ON MLOG$_MV_XXX (SNAPTIME$$, CHANGE_VECTOR$$) ONLINE - 若日志表已积压，先清空再建索引；否则索引创建过程自身就可能触发
ORA-01652
存储过程内显式处理 CLOB 时的三个高危操作
以下写法在 PL/SQL 中看似合理，实则极易触发临时段膨胀：
-
SELECT ... INTO clob_var FROM t WHERE ... ORDER BY clob_col：CLOB 列不能作为ORDER BY键，但 Oracle 不报错，而是降级为全字段排序并 spill -
INSERT INTO t2 SELECT DISTINCT clob_col FROM t1：DISTINCT强制去重排序，CLOB 比较必须落盘 - 用
DBMS_LOB.SUBSTR截取后参与GROUP BY：子串结果仍属 LOB 类型，未转成VARCHAR2就进分组，照样排序
安全做法是：先用 DBMS_LOB.SUBSTR(clob_col, 4000, 1) 转成 VARCHAR2，再 CAST(... AS VARCHAR2(4000)) 显式类型转换，确保后续操作走字符路径而非 LOB 路径。
临时表空间无法释放的隐藏原因：长期未提交的 LOB 事务
CLOB 写入（DBMS_LOB.WRITE、APPEND）若在长事务中执行，即使 SQL 执行完，临时段也不会立即释放——因为 Oracle 需保留回滚信息供一致性读。这类会话在 V$TEMPSEG_USAGE 中表现为 SEGTYPE = 'LOB_DATA' 且 SESSION_ADDR 持续存在。
- 定位语句：
SELECT s.sid, s.serial#, s.sql_id, t.segtype, t.blocks FROM v$session s, v$tempseg_usage t WHERE s.saddr = t.session_addr AND t.segtype = 'LOB_DATA' - 确认后，优先
COMMIT或ROLLBACK对应会话，比直接KILL SESSION更安全 - 避免在循环中反复
DBMS_LOB.WRITE而不提交；批量写入后加COMMIT，或改用DBMS_LOB.LOADFROMFILE减少交互次数
真正棘手的不是空间不够，而是你看到 V$TEMP_SPACE_HEADER.USED_BYTES 居高不下，却找不到活跃 SQL——那大概率是某个没提交的 CLOB 事务锁住了临时段，且不会随时间自动释放。
