pga不足的典型信号是ora-04030报错或awr中sorts(disk)、hash joins(disk)骤升；需先确认workarea自动管理是否生效，再结合pga memory advisory的estd pga overalloc count=0和磁盘读写不再下降来科学设定pga_aggregate_target。
ORA-04030报错或sorts (disk)飙升，基本就是PGA不够了
别急着调pga_aggregate_target，先确认是不是真缺——典型信号有两个：ORA-04030错误频繁出现，或者AWR里sorts (disk)、hash joins (disk)统计值突然拉高。这两个指标在“SQL Statistics → Memory Statistics”页里直接可见，不是估算值，是真实落盘次数。如果Workarea executions – multipass非零，说明已经有操作反复读写临时表空间，必须干预。
用ASH定位吃内存的SQL，但得避开采样盲区
查DBA_HIST_ACTIVE_SESS_HISTORY能揪出高内存消耗的sql_id，但结果依赖ASH采样完整性。常见坑是：没开ASH、保留时间太短（比如只留1小时），或者问题SQL执行太快（
- 优先运行这个查询，重点看
pga_mb和execs比值高的SQL： 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;- 如果没结果，立刻切到实时视图
V$SQL_WORKAREA_ACTIVE查当前正在跑的大内存操作 - 注意：
pga_memory_used字段在12c+才稳定可用，11g建议结合V$SQL_WORKAREA的actual_mem_used
检查workarea自动管理是否真的生效
pga_aggregate_target只是Oracle算每个workarea大小的基数，不是“最大可用PGA”。它起效的前提是整套自动管理没被绕过。最容易被忽略的是残留的手动参数。
- 运行
SHOW PARAMETER workarea_size_policy，确保返回AUTO；如果不是，立刻ALTER SYSTEM SET workarea_size_policy=AUTO - 查
sort_area_size和hash_area_size是否为0，非零就说明session级或系统级手动模式还在生效 - 检查SQL里有没有
+ OPT_PARAM('_smm_max_size' 'xxx')这类hint，它们会直接覆盖自动估算 - 确认没在应用连接里执行过
ALTER SESSION SET sort_area_size = ...
看PGA Memory Advisory时盯死两个硬指标
AWR报告里的PGA建议不是看“越大越好”，而是卡两条线：Estd PGA Overalloc Count = 0，且Estd Extra W/A MB Read/Written to Disk不再随目标增大而下降。前者代表不会因内存不足被迫扩堆，后者代表排序/哈希已基本在内存完成。
- 如果
PGATarget Est (MB)设为2GB时Estd PGA Overalloc Count是12，设为2.5GB时变成0，那底线就是≥2.5GB - 如果从3GB加到3.5GB，
Estd Extra W/A MB Read/Written只从8.2MB降到8.19MB，再加没意义 - 注意：这个建议值会被单次大报表拉高，得结合业务周期人工过滤——比如避开月底结账窗口期的数据
真正难的不是算出数字，而是区分“SQL本身workarea预估失准”和“纯内存不足”。前者要改SQL或加hint，后者才调参数。multipass操作大概率属于前者，别一上来就加内存。
