ORA-01652根本原因是临时段分配失败，多由HASH JOIN或SORT-MERGE JOIN溢出导致，需先通过V$SQL_PLAN、V$SQL_WORKAREA和V$SORT_USAGE定位是否哈希溢出，再调优PGA配置或改写执行计划，而非盲目扩容。
大规模表关联（尤其是 HASH JOIN 或 SORT-MERGE JOIN）极易触发磁盘排序和哈希溢出，直接吃掉临时表空间，导致 ORA-01652。这不是“加文件就能解决”的容量问题，而是执行计划与内存配置不匹配的信号。
查清是不是 HASH JOIN 在溢出
临时表空间暴增往往不是因为 SQL 写得差，而是优化器选了 HASH JOIN，但 PGA_AGGREGATE_TARGET 或 WORKAREA_SIZE_POLICY 不够，导致哈希区撑爆后全写到 TEMP。先确认当前执行是否真在溢出：
- 运行
SELECT * FROM V$SQL_PLAN WHERE SQL_ID = 'xxx' AND OPERATION LIKE '%HASH%' AND OPTIONS = 'JOIN'，看是否有TEMPSEG_SIZE非零值 - 查
V$SQL_WORKAREA：若ACTUAL_MEM_USED > MAX_MEM_USED或NUMBER_PASSES > 1，说明已发生多次磁盘往返 -
V$SORT_USAGE中SEGTYPE = 'HASH'的记录持续增长，基本可锁定是哈希溢出
调小 hash_area_size 或改用 sort-merge（Oracle 11g+）
在无法立刻调大 PGA 的情况下，主动限制单个哈希操作的内存上限，反而能减少极端溢出风险——尤其适用于 OLTP 环境中偶发的大关联：
- 会话级临时生效：
ALTER SESSION SET "_hash_join_bucket_size" = 4096（降低桶大小，减缓膨胀速度） - 强制走
SORT-MERGE JOIN：SELECT /*+ USE_MERGE(t1,t2) */ ...，前提是关联字段都有索引且已收集统计信息 - 禁用哈希连接（慎用）：
ALTER SESSION SET "_optimizer_hash_join_enabled" = FALSE，仅用于紧急定位 - 注意：Oracle 12c+ 默认启用
INMEMORY和自适应执行计划，_hash_join_bucket_size等隐含参数影响变小，优先检查OPTIMIZER_ADAPTIVE_PLANS = TRUE是否引发计划反复切换
避免关联前未过滤就急着 JOIN
很多“大表关联”问题根源不在 JOIN 本身，而在 JOIN 前没做有效剪枝。临时段爆炸常发生在中间结果集远超预期时：
- 检查
WHERE条件是否下推失败：比如写了UPPER(col) = 'X'却没函数索引，导致全表扫描后再 JOIN - 用
/*+ MATERIALIZE */提前物化子查询（Oracle 12c+ 支持），把中间结果固化为临时表，避免重复计算和多次溢出 - 对大表关联，优先确保驱动表（小结果集）在 LEFT/INNER JOIN 的左侧，并加
/*+ LEADING(t_small) */固定顺序 - 如果关联字段存在大量 NULL，
HASH JOIN会为 NULL 单独建桶，加剧内存压力；考虑NVL(col, -1)统一处理（需同步加函数索引）
别只盯着 TEMP 文件扩容，先看 PGA 是否被低估
临时表空间只是“症状”，PGA_AGGREGATE_TARGET 才是“病根”。一个 32G 内存的数据库，设 PGA_AGGREGATE_TARGET=1G 是常见误配：
- 查当前 PGA 使用峰值：
SELECT NAME, VALUE FROM V$PGASTAT WHERE NAME IN ('aggregate PGA auto target', 'total PGA allocated', 'maximum PGA allocated') - 若
maximum PGA allocated接近PGA_AGGREGATE_TARGET，且V$PGASTAT中bytes processed远高于extra bytes read/written，说明多数操作还在内存完成；反之则已频繁溢出 - 生产库建议 PGA 至少占物理内存的 20%～25%，OLAP 类系统可上探至 40%；但必须配合
PGA_AGGREGATE_LIMIT防止失控（例如设为PGA_AGGREGATE_TARGET * 2） - Resource Manager consumer group 可绑定
ACTIVE_SESS_POOL_P1和PGA_AGGREGATE_LIMIT，比全局调参更安全
真正难处理的不是“TEMP 满了”，而是多个会话同时触发哈希溢出、又共享同一个 TEMP 表空间——这时 coalesce、resize 都来不及救火。最有效的防线，其实是让每个关键业务模块（ETL / 报表 / 实时查询）使用独立的临时表空间，并通过 ALTER USER ... TEMPORARY TABLESPACE 绑定，把故障域切开。
