ORA-01652根因是物化视图刷新SQL中WINDOW SORT等操作需连续大块临时段，而空闲块碎片化；需通过跟踪定位、建复合索引、清日志、禁用原子刷新及更新统计信息解决。
物化视图刷新报ORA-01652，不是磁盘不够，是执行计划卡在排序上
直接加临时文件或调pga_aggregate_target基本无效——物化视图刷新走的是服务器进程，不读会话级内存参数，也不受sort_area_size影响。真正爆掉临时空间的，是刷新sql里隐含的window sort、sort group by或temp table transformation，它们需要连续大块临时段，而现有v$sort_segment里空闲块太碎。
先确认是不是它在作祟：
- 跟踪刷新会话：DBMS_MONITOR.SESSION_TRACE_ENABLE，用tkprof看执行计划，找TempSpc列 > 10G 且Operation含WINDOW SORT的行
- 查实时占用：SELECT sql_id, tablespace, segtype, blocks * 8 / 1024 AS gb FROM v$tempseg_usage WHERE segtype = 'DATA'，关联v$session确认是不是MERGE INTO MV_XXX本身在刷
让刷新避开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 */，彻底绕开排序逻辑
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——这时加文件、调参数都白搭。
修复动作必须包含：
- 立即收集统计信息：DBMS_STATS.GATHER_TABLE_STATS跑一遍物化视图基表和日志表
- 检查dba_indexes里索引状态是否VALID，clustering_factor是否异常高
- 若用绑定变量，警惕_optimizer_bind_aware触发的执行计划突变，必要时加/*+ OPT_PARAM('_optimizer_adaptive_plans' 'FALSE') */固化路径
