AWR报告中判断PGA是否合理需看三处：PGA Memory Advisory中SIZE_FACTOR≥1.0行的Est PGA Overalloc Count＞0即表明已溢出；SQL Statistics中Workarea executions–multipass非零必须处理；Top 5 Timed Events出现direct path read/write temp即证实磁盘排序发生。
awr报告里能直接判断pga是否合理，关键看三处：pga memory advisory里的est pga overalloc count、sql statistics里workarea executions – multipass是否非零、以及top 5 timed events里有没有direct path read temp或direct path write temp。
查PGA Memory Advisory确认是否真超限
这个视图不是“建议调大多少”，而是告诉你当前pga_aggregate_target下，工作区是否已被迫溢出。重点看SIZE_FACTOR ≥ 1.0行的Est PGA Overalloc Count列：
- 只要该值 > 0，就说明有排序/Hash Join/位图运算实际写入了临时表空间——这不是偶尔抖动，是硬性不足
- 如果
SIZE_FACTOR = 1.2时该值降为 0，但SIZE_FACTOR = 1.0时是 187，说明当前配置就是瓶颈点，不是“再加一点就好” - 别信
Est PGA Cache Hit %高就没事——它只统计“已分配工作区”的命中率，不反映根本没分到内存的请求
翻SQL Statistics看workarea执行模式分布
去AWR报告的「SQL Statistics → Memory Statistics」部分，盯紧这三列：
-
Workarea executions – optimal：理想状态，全内存完成 -
Workarea executions – one-pass：单次落盘，性能已打折扣，占比超 5% 就该干预 -
Workarea executions – multipass：多次读写临时表空间，出现任何非零值都必须处理
注意：multipass几乎总是SQL写法或数据倾斜导致（比如ORDER BY字段高基数+无索引），不是单纯调大pga_aggregate_target能解决的。
结合等待事件和后台进程定位真实消耗源
ORA-04030报错或direct path read temp等待高，不等于前台SQL在吃内存：
- 检查「Background Processes」小节：若
ora_mmon_*、ora_d000_*、ora_cjq0_*出现在PGA Memory Top 5，说明自动内存监控、调度作业或GC协调在持续占内存 - 用ASH抓实时高消耗：
SELECT session_id, program, pga_allocated/1024/1024 MB FROM v$active_session_history WHERE pga_allocated > 200*1024*1024 AND sample_time > SYSDATE - 1/24 ORDER BY pga_allocated DESC;，program字段比sql_id更可信 - RAC环境必须逐实例查——
SID='rac1'和SID='rac2'的_pga_aggregate_limit生效条件可能完全不同
真正容易被忽略的是：12c+启用inmemory_size后，pga_aggregate_target和inmemory_area会争抢同一片OS内存；而_pga_aggregate_limit是否生效，完全取决于memory_target是否>0——设了pga_aggregate_target反而会让它失效。
