awr中sorts (disk)占比超5%、workarea executions–multipass非零、ora-04030报错与磁盘排序突增时段吻合，即确认pga真实溢出；应查ash中on cpu时段的pga内存消耗sql，而非仅看总cpu排序。
AWR里sorts (disk)非零、Workarea executions – multipass出现，基本就是PGA溢出在拖垮SQL性能——但直接调大PGA_AGGREGATE_TARGET常无效，得先确认是不是真被撑爆、谁在吃、为什么预估失准。
怎么从AWR快速确认PGA真溢出了
别只看PGA_AGGREGATE_TARGET设了多少。重点盯三个信号：
-
sorts (disk)/ (sorts (memory)+sorts (disk)) > 5% → 磁盘排序已成常态 - AWR报告中「SQL Statistics → Memory Statistics」页，
Workarea executions – multipass值非零 → 工作区反复读写临时表空间，严重瓶颈 -
ORA-04030报错出现在alert log，且时间点与AWR中sorts (disk)突增时段吻合
查哪条SQL在吃PGA：别信“总CPU”排序
AWR默认按累计CPU排SQL，但PGA压力往往来自短时高内存操作。要查真实消耗者：
- 运行查询：
SELECT sql_id, ROUND(SUM(pga_memory_used)/1024/1024, 1) AS pga_mb, COUNT(*) AS execs FROM dba_hist_active_sess_history a JOIN dba_hist_sqlstat s USING (sql_id) WHERE sample_time > SYSDATE - 1 AND session_state = 'ON CPU' GROUP BY sql_id ORDER BY pga_mb DESC FETCH FIRST 10 ROWS ONLY;
- 结果依赖
DBA_HIST_ACTIVE_SESS_HISTORY采样完整性；若ASH保留时间太短或未启用，会漏掉 - 同一
sql_id在不同快照里pga_mb波动剧烈（比如从50MB跳到800MB），说明执行计划或数据分布突变，不是配置问题
为什么workarea_size_policy=AUTO还溢出
自动管理生效的前提常被忽略：
- 查
SHOW PARAMETER workarea_size_policy，确保返回AUTO；若为MANUAL，则sort_area_size等参数会覆盖自动策略 - 检查是否残留hint：
/*+ OPT_PARAM('_smm_max_size' '102400') */这类会强制压低单次workarea上限 - 查
V$PGASTAT中cache hit percentage是否PGA_AGGREGATE_TARGET过小或SQL并发太高 - 19c优化器更倾向物化中间结果，尤其在含
UNION ALL、ROW_NUMBER() OVER的复杂视图中，即使统计信息准确也容易预估失准
紧急压制和长期修复的分界点在哪
临时手段只能救火，真正卡点藏在SQL写法和数据特征里：
- 会话级压制有效但不可持续：
ALTER SESSION SET "_sort_elimination_cost_ratio" = 10000;+ALTER SESSION SET WORKAREA_SIZE_POLICY = MANUAL; SORT_AREA_SIZE = 209715200; - 长期修复必须下钻到SQL：在AWR中找「SQL ordered by Temp Space」，挑
Physical Reads Per Exec > 5000且含ORDER BY/GROUP BY的语句，重点检查谓词是否含隐式转换（如to_char(create_time) = '2026-06'） - 调大
PGA_AGGREGATE_TARGET前，先按公式算：OLTP环境建议≈20% ×SGA_TARGET；盲目超过40%可能挤占DB_CACHE_SIZE，反而引发db file sequential read等待
最易被忽略的是：Workarea executions – one-pass占比超5%时系统已开始承压，但AWR不会报警；这时sorts (disk)还没上量，ORA-04030也没触发，却已是溢出前夜。
