物化视图刷新卡在WINDOW SORT的根本原因是日志表缺索引或积压导致优化器退化为全表扫描+大排序，而非磁盘空间不足；必须建复合索引、清理日志、慎用ATOMIC_REFRESH=FALSE，并避免调SORT_AREA_SIZE等无效参数。
为什么物化视图刷新总卡在 WINDOW SORT？
物化视图刷新时出现 ora-01652 或会话长时间占用大量 temp 空间，几乎从不是磁盘不够，而是执行计划里塞了 window sort 或 sort group by。这类操作不走 pga 排序区，强制依赖临时表空间里的连续块——一旦日志表 mlog$_mv_xxx 缺索引或积压过久，oracle 就放弃索引扫描，退化为全表扫 + 大排序。
- 查真实瓶颈：用
V$TEMPSEG_USAGE关联V$SESSION，确认SQL_ID是否指向MERGE INTO MV_XXX本身，还是底层日志表的全表扫描 - 看执行计划：重点盯
TempSpc列 > 10G 的行，Operation 含WINDOW SORT就是根因 - 别只看
DBA_TEMP_FILES总大小——临时段分配失败，99% 是因为缺乏足够大的连续空闲块，而非总量不足
如何让刷新避开 WINDOW SORT？
核心是让 Oracle 在读取物化视图日志时走索引，而不是扫全表再排序。这不靠调 PGA_AGGREGATE_TARGET，而靠日志结构和刷新参数组合。
- 必须建复合索引：
CREATE INDEX idx_mlog_snap ON MLOG$_MV_XXX (SNAPTIME$$, CHANGE_VECTOR$$) ONLINE;—— 没这个索引，SNAPTIME$$过滤就失效，必然触发排序 - 刷新前清理日志：
EXEC DBMS_MVIEW.PURGE_LOG('MV_XXX', 1, 'COMMIT_SCN');，防止一次处理几万行无用变更 - 慎用
ATOMIC_REFRESH => FALSE：它跳过MERGE路径，直接TRUNCATE+INSERT /*+ APPEND */，但仅适用于不含聚合、连接、ROWNUM的 MV；否则刷新失败 - 检查日志是否启用
SEQUENCE和ROWID：SELECT ROWIDS, SEQUENCE FROM USER_MVIEW_LOGS WHERE MASTER = 'YOUR_TABLE';，任一为NO，FAST 刷新必退化
哪些参数对刷新时的排序内存实际无效？
SORT_AREA_SIZE 和 PGA_AGGREGATE_TARGET 对物化视图刷新基本不起作用——因为刷新由服务器进程（server process）执行，不读用户会话级设置。真正影响排序行为的是执行路径选择和临时表空间配置。
-
TEMP表空间必须有足够大的单个数据文件（建议 ≥ 2GB），避免碎片化导致无法分配连续块 - 不要用
ALTER SESSION SET SORT_AREA_SIZE = ...去“优化”刷新，它只影响当前会话的 SQL，不影响DBMS_MVIEW.REFRESH内部生成的语句 - 如果必须控制内存使用，唯一有效手段是改写 MV 定义：去掉
COUNT(*)、GROUP BY TO_CHAR(...)等易触发SORT GROUP BY的写法
RAC 环境下排序溢出更难扛，怎么防？
RAC 各节点的临时表空间不共享，WINDOW SORT 一旦溢出到磁盘，就会争抢全局锁和 DFS 资源，极易出现 enq: TX - row lock contention 或 ORA-12008。
- 禁用本地临时段：
CREATE GLOBAL TEMPORARY TABLE替代CREATE GLOBAL TEMPORARY TABLE ON COMMIT DELETE ROWS，后者依赖会话状态，在 RAC 中不可靠 - 降低并行度：
PARALLELISM => 1或2，Oracle 11g 对 RAC 下并行 DML 的资源协调能力弱，设高反而加剧锁等待 - 确保所有节点对共享路径（如
'+DATA/mv_logs/'）有读写权限，避免因路径缺失导致任务调度失败后重试堆积
真正难调的从来不是内存参数，而是日志表是否干净、索引是否到位、MV 定义是否“友好”。一个积压 50 万行的日志表，再大的 TEMP 表空间也救不了——它只会把排序压力从内存转移到磁盘，然后卡死。
