物化视图预聚合不占PGA/SGA，但刷新和查询重写易致内存超标；常见ORA-04030、高sorts(memory)与temp空间；主因是分区未对齐、全量刷新、MV日志滥用及重写过度；应启用PCT、分区级刷新、对齐分区键、限制重写深度并加冗余分区谓词。
物化视图预聚合本身不直接占用 PGA/SGA，但刷新和查询重写过程会显著推高内存使用。尤其在分区表上做多维聚合（如按时间+区域+产品层级汇总），若未控制粒度与刷新方式，DBMS_MVIEW.REFRESH 可能触发全分区扫描、大排序、临时段膨胀，导致 PGA spike 甚至 ORA-04030。
为什么分区表 + 物化视图容易内存超标
常见错误现象：ORA-04030: out of process memory 出现在 DBMS_MVIEW.REFRESH 或复杂查询重写执行时；AWR 报告中 sorts (memory) 和 temp space allocated 指标异常高。
- 快速刷新（
'F'）依赖 MV 日志，日志表本身无分区，单次刷新可能扫描整个日志段，触发大排序 - 全量刷新（
'C'）默认重建整个 MV，即使只改了 1 个分区，也会重跑全部聚合逻辑 - 查询重写启用
QUERY_REWRITE_ENABLED=FORCE后，优化器可能选择代价估算不准的重写路径，引发大中间结果集 - 分区表上建的物化视图若未对齐源表分区键（如源表按
time_idRANGE 分区，MV 却按regionLIST 分区），无法利用分区裁剪，扫描范围失控
刷新阶段：用 PCT 替代 MV 日志 + 按需刷新分区
Oracle 10gR2 起支持分区更改跟踪（PCT），无需 MV 日志即可识别变更分区，大幅降低刷新内存压力。
- 确认源表已分区且 MV 定义中包含
ENABLE QUERY REWRITE和ENABLE ON QUERY COMPUTATION - 删除原有 MV 日志（如果存在）：
DROP MATERIALIZED VIEW LOG ON sales_tab，避免日志维护开销 - 刷新时指定分区级粒度：
DBMS_MVIEW.REFRESH('sales_mv', 'F', partition_name => 'SALES_Q1_2026') - 确保物化视图也按相同列（如
time_id）分区，并启用 PCT：ALTER MATERIALIZED VIEW sales_mv ENABLE ROW MOVEMENT
查询阶段：限制重写深度 + 强制分区裁剪
查询重写不是“越智能越好”，过度重写反而生成嵌套物化视图引用链，中间结果驻留 PGA 时间变长。
- 禁用跨 MV 重写（默认关闭，但显式设更安全）：
ALTER SESSION SET query_rewrite_integrity = STALE_TOLERATED，避免因多个 MV 状态不一致触发额外校验 - 在业务 SQL 中显式加分区谓词，哪怕只是冗余条件：
WHERE time_id >= DATE '2026-04-01' AND time_id ，确保优化器走分区裁剪路径 - 对高频查询，用
/*+ REWRITE(sales_mv) */提示强制使用特定 MV，跳过重写决策开销 - 定期检查重写是否生效：
EXPLAIN PLAN FOR SELECT ...; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);，关注REWRITE行是否出现，以及partition start/partition stop是否为具体分区名而非KEY
容易被忽略的细节：基表收缩与 MV 日志清理不解决刷新内存问题
很多人误以为 shrink 基表或 MLOG$ 表能缓解刷新内存压力——其实不能。shrink 解决的是 HWM 和空块，而刷新卡顿主因是排序、哈希连接、临时段分配。真正有效的动作是：严格对齐分区键、关闭不必要的重写链、用 PCT 替代日志、以及把 PGA_AGGREGATE_TARGET 设置为可预测值（例如设为物理内存的 20%），避免自动扩展失控。
