ORA-01652根源是物化视图刷新SQL触发WINDOW SORT等操作需连续大临时段，而非磁盘不足；应通过跟踪执行计划、查v$tempseg_usage定位SQL_ID、建日志复合索引、清过期日志、设ATOMIC_REFRESH=FALSE及更新统计信息来解决。
ORA-01652 不是磁盘不够，是物化视图刷新 SQL 生成了 WINDOW SORT、SORT GROUP BY 或 TEMP TABLE TRANSFORMATION，需要连续大块临时段，而 v$sort_segment 里空闲块太碎——加临时文件或调 pga_aggregate_target 基本无效。
怎么确认是物化视图刷新在吃临时空间
别只看 DBA_TEMP_FILES 总大小。真正卡点藏在执行计划和实时段占用里：
- 用
DBMS_MONITOR.SESSION_TRACE_ENABLE跟踪刷新会话，tkprof解析后重点找Operation含WINDOW SORT且TempSpc> 10G 的行 - 查
v$tempseg_usage关联v$session，确认SQL_ID是否属于MERGE INTO MV_XXX或底层日志表（如MLOG$_MV_XXX）全表扫描 - 检查
v$sort_segment中STATUS = 'ACTIVE'且blocks持续不降的段，对应刷新SQL_ID就是真凶
怎么让刷新避开 WINDOW SORT
物化视图日志（MLOG$_MV_XXX）积压或字段含 CLOB 时，Oracle 默认按 SNAPTIME$$ 全表排序合并，这是 WINDOW SORT 主因。优化靠改路径，不靠调参数：
- 给日志表建复合索引：
CREATE INDEX idx_mlog_snap ON MLOG$_MV_XXX (SNAPTIME$$, CHANGE_VECTOR$$) ONLINE，避免全表扫后排序 - 刷新前清过期日志：
EXEC DBMS_MVIEW.PURGE_LOG('MV_XXX', 1, 'COMMIT_SCN')，从源头剔除几万行无用变更 - 禁用原子刷新：
DBMS_MVIEW.REFRESH('MV_XXX', METHOD => 'F', ATOMIC_REFRESH => FALSE)，跳过MERGE分支，改走TRUNCATE + INSERT /*+ APPEND */
为什么调 SORT_AREA_SIZE 或 PGA_AGGREGATE_TARGET 无效
物化视图刷新走的是服务器进程（server process），不是用户会话，它不读 ALTER SESSION 设的值，也不受 sort_area_size 影响。真正起作用的是执行计划本身和临时表空间配置：
-
PGA_AGGREGATE_TARGET对刷新过程几乎无影响，强行调高只会掩盖问题 - 临时段分配由优化器决定：若基表统计信息过期，优化器可能为日志表选错执行路径（全表扫描+排序），而非索引范围扫描
- 必须同步更新基表和日志表的统计信息：
DBMS_STATS.GATHER_TABLE_STATS，否则即使索引建了也用不上
RAC 环境下加临时文件的陷阱
在 RAC 中执行 ALTER TABLESPACE TEMP ADD TEMPFILE，若没验证 ASM 路径一致性或磁盘组状态，可能只在一个节点生效，甚至引发节点假死：
- 查所有节点 ASM 挂载状态：
asmcmd lsdg DATADG，确认State = MOUNTED且Usable_file_mb > 0 - 路径必须用 ASM 别名（如
'+DATADG'），不能用物理路径；示例：ALTER TABLESPACE TEMP ADD TEMPFILE '+DATADG' SIZE 32G AUTOEXTEND OFF - 禁用
AUTOEXTEND ON——RAC 节点间扩展协调延迟高，生产环境一律用AUTOEXTEND OFF+ 预留足够初始大小
最常被忽略的根因是统计信息过期导致执行计划突变：一个 200 万行的基表，统计信息半年没更新，优化器仍按 1 万行估算，结果选错连接方式，HASH JOIN 把中间结果全写进 TEMP——这时加任何临时文件都只是延缓报错时间。
