sort_area_size对物化视图刷新完全无效，因其由服务器进程执行，不继承用户会话设置；真正影响排序的是执行计划中的window sort等操作，需通过索引优化、日志清理或atomic_refresh=false绕过排序瓶颈。
别调 sort_area_size —— 它对物化视图刷新完全无效。
为什么 SORT_AREA_SIZE 在 MV 刷新里不起作用
物化视图刷新由后台服务器进程（server process）执行，不继承用户会话的 SORT_AREA_SIZE 或 PGA_AGGREGATE_TARGET 设置。即使你 ALTER SESSION SET SORT_AREA_SIZE = 209715200，刷新语句依然走 Oracle 内部工作区策略，该参数被忽略。
- 真正影响排序资源分配的是执行计划中是否触发
WINDOW SORT、SORT GROUP BY或TEMP TABLE TRANSFORMATION这类操作 - 这些操作的临时段需求由优化器根据统计信息、索引可用性、日志表结构动态决定，和会话级排序参数无关
- 在 Oracle 19c 中，
SORT_AREA_SIZE已是废弃参数（仅兼容），官方文档明确标注 “not used for automatic memory management”
查清到底是哪条 SQL 在吃临时空间
不能只看 DBA_TEMP_FILES 总大小，要定位到具体刷新步骤：
- 用
DBMS_MONITOR.SESSION_TRACE_ENABLE(session_id => <sid>, waits => TRUE, binds => FALSE)</sid>跟踪刷新会话 - 用
tkprof解析 trace 文件，搜索TempSpc列 > 1GB 的行，重点关注Operation含WINDOW SORT或SORT GROUP BY的记录 - 关联
V$TEMPSEG_USAGE和V$SESSION，确认SQL_ID是否属于MERGE INTO MV_XXX本身，还是底层MLOG$_MV_XXX全表扫描后被迫去重
真正有效的三类干预手段
绕过排序瓶颈，不是加内存，而是改路径：
- 给物化视图日志表加复合索引：
CREATE INDEX idx_mlog_snap ON MLOG$_MV_XXX (SNAPTIME$$, CHANGE_VECTOR$$) ONLINE;，让刷新能索引范围扫描，避免全表扫+排序 - 刷新前清理积压日志：
EXEC DBMS_MVIEW.PURGE_LOG('MV_XXX', 1, 'COMMIT_SCN');，防止 WINDOW SORT 处理数万行已失效变更 - 强制跳过 MERGE 排序分支：
DBMS_MVIEW.REFRESH('MV_XXX', METHOD => 'F', ATOMIC_REFRESH => FALSE);，此时走 TRUNCATE + INSERT APPEND，不生成中间排序段
容易被忽略的 SYSTEM 表空间连带风险
当刷新频繁失败重试，IDL_UB1$ 等数据字典表可能因 PL/SQL 单元反复编译而膨胀，撑爆 SYSTEM 表空间——这和 TEMP 无关，但现象相似（登录慢、ORA-02002）。必须定期检查：
SELECT SEGMENT_NAME, SUM(bytes)/1024/1024 AS size_mb FROM dba_segments WHERE tablespace_name = 'SYSTEM' GROUP BY SEGMENT_NAME ORDER BY size_mb DESC FETCH FIRST 5 ROWS ONLY;- 若
IDL_UB1$排前三，说明刷新异常已引发字典层副作用，需先停刷、清理日志、再重建 MV
