ORA-01652报错需先排查真实原因而非盲目扩容；应查gv$TEMP_SPACE_HEADER实时占用、v$sort_usage定位高耗会话与SQL，关注blocks值；重点优化ORDER BY/GROUP BY/ HASH JOIN等易溢出操作，合理设置PGA、索引及连接条件，并及时清理残留临时段。
ORA-01652报错时，先确认是不是真缺空间
看到 ora-01652 就加文件，容易掩盖真实瓶颈。临时表空间“爆满”不等于磁盘没空间，更可能是某次操作瞬间占满、释放滞后，或多个会话争抢同一临时段。先查清楚谁在用、用了多少、用多久：
- 运行
SELECT tablespace_name, SUM(bytes_used)/1024/1024 AS used_mb FROM gv$TEMP_SPACE_HEADER GROUP BY tablespace_name看实时占用，注意是gv$视图（RAC需跨实例汇总） - 查正在撑爆空间的会话：
SELECT s.sid, s.username, u.blocks * p.value / 1024 / 1024 AS mb_used, sql.sql_text FROM v$sort_usage u, v$session s, v$sql sql, v$parameter p WHERE u.session_addr = s.saddr AND s.sql_hash_value = sql.hash_value(+) AND p.name = 'db_block_size' - 重点看
blocks列——它反映当前未释放的临时段大小，不是历史峰值
存储过程中 ORDER BY / GROUP BY 导致临时空间暴涨
存储过程里嵌套多层子查询、带 ORDER BY 的游标循环、或 GROUP BY 聚合大量数据，极易触发磁盘排序。PGA 内存不够时，Oracle 不会提示“内存不足”，而是直接写 TEMP。
- 检查该过程执行计划中的
Used-Mem和O/1/M字段：若出现MULTI-PASS，说明已多次读写磁盘，性能和空间消耗双恶化 - 避免在游标定义中写
ORDER BY；改用应用层排序，或确保关联字段有索引支撑排序条件 - 对大表
GROUP BY，优先考虑预聚合或物化中间结果，而不是让每次调用都重算 - 临时表（
CREATE GLOBAL TEMPORARY TABLE）本身不占永久表空间，但其上的INDEX或后续JOIN操作仍会用 TEMP —— 别忘了给 GTT 加索引
存储过程内 HASH JOIN 溢出到 TEMP 的典型诱因
存储过程调用的 SQL 若含 HASH JOIN，且驱动表（Build Table）过大，就会把哈希分区写进临时表空间。执行计划里 1Mem（One-Pass 内存上限）远小于 Used-Mem 是明确信号。
- 确认驱动表是否真的需要全量参与连接：加
WHERE条件提前过滤，比连接后再WHERE更省 TEMP - 避免在存储过程中拼接出超大驱动集，例如
SELECT /*+ USE_HASH(t1 t2) */ ... FROM (SELECT ... FROM big_table WHERE ...) t1 JOIN small_table t2—— 子查询结果可能远超 PGA 单工作区上限（通常 ≤2GB） - 并行度（
PX）不是万能解药：每个 PX 进程仍受限于自身 PGA 分配，高并发下反而加剧 TEMP 争用 - 临时表空间位置影响极大：如果
tempfile在机械盘或共享存储上，MULTI-PASS的 I/O 延迟会拖垮整个存储过程响应时间
别只盯着扩容，临时表空间的生命周期管理常被忽略
临时段在事务提交后释放，但会话不退出就一直挂着。存储过程若长连接、复用会话（如连接池）、或异常中断未清理，v$sort_usage 里残留的 blocks 可能持续数小时。
- 不要依赖“自动释放”：显式加
COMMIT或ROLLBACK后再退出关键逻辑块，尤其在异常分支里补EXCEPTION WHEN OTHERS THEN ROLLBACK; -
ALTER TABLESPACE temp SHRINK SPACE只回收空闲空间，无法清理活动会话的临时段；真正有效的释放动作是终止对应会话（ALTER SYSTEM KILL SESSION 'sid,serial#'） - 监控脚本里别只查
dba_temp_files.bytes，那只是文件大小；要盯gv$TEMP_SPACE_HEADER.bytes_used+v$sort_usage.blocks组合，才能判断是真缺空间，还是“僵尸临时段”占着茅坑
