pga过载的典型信号是awr中workarea executions – one-pass占比超5%或multipass非零，表明排序/哈希操作被迫落盘；并非等待ora-04030报错才干预。
PGA过载的典型信号是什么
不是看ORA-04030报错才动手——等报错出现，说明已经发生内存分配失败。真正要盯的是AWR报告里「SQL Statistics → Memory Statistics」页中的三列：Workarea executions – optimal、Workarea executions – one-pass、Workarea executions – multipass。只要one-pass占比超过5%，或multipass非零，就代表部分排序/哈希操作被迫落盘，PGA已实际过载。
常见误判：只看PGA Aggr Target没被“用满”，就认为没问题。但Oracle按pga_aggregate_target估算单个workarea大小，若SQL预估偏差大（比如统计信息陈旧），哪怕总内存充足，单个操作仍可能被强制写临时表空间。
怎么确认是PGA导致的磁盘写入，而不是临时表空间本身慢
关键在分离归因：PGA过载引发的是逻辑落盘行为，而临时表空间I/O慢是物理响应延迟。两者表现不同：
-
one-pass/multipass升高 +temp space allocated暴涨 +db file sequential read等待未同步上升 → 问题在PGA预估或SQL本身 -
db file sequential read等待时间（Av Rd ms）在temp表空间对应文件上显著高于其他数据文件 → 临时表空间存储层真慢
查具体文件延迟，用这个语句（注意单位是百分之一秒）：
SELECT f.file_name,
ROUND((f.readtim / NULLIF(f.phyrds, 0)) / 10, 2) AS avg_read_ms
FROM dba_hist_filestatxs f
JOIN dba_hist_snapshot s ON f.snap_id = s.snap_id
WHERE s.begin_interval_time BETWEEN SYSDATE-1 AND SYSDATE
AND f.file_name LIKE '%temp%'
如果avg_read_ms正常（SSD multipass高，就坐实是PGA侧问题。
哪些SQL最可能触发PGA过载落盘
不是执行时间长的SQL，而是那些中间结果集大 + 优化器预估严重失准的语句。重点关注AWR中以下特征的sql_id：
-
Buffer Gets Per Exec> 50000 且Physical Reads Per Exec也高 → 可能全表扫描后接大排序 -
Executions低但Rows Processed极高 → 单次处理海量数据，如ETL任务 - 执行计划含
SORT-AGGREGATE或HASH JOIN，且PSTART/PSTOP为ALL→ 分区裁剪失效，实际处理远超预估
用DBMS_XPLAN.DISPLAY_AWR查历史执行计划时，重点比对ESTIMATED_ROWS和ACTUAL_ROWS是否差两个数量级以上。
调参前必须验证的三个前提
盲目调大pga_aggregate_target可能无效，甚至恶化争用。先确认：
-
workarea_size_policy确实是AUTO（不是MANUAL），否则pga_aggregate_target不生效 - 没有SQL硬编码
+ OPT_PARAM('_smm_max_size' 'xxx')这类hint，它会覆盖全局设置 - 实例级没设
sort_area_size或hash_area_size（SHOW PARAMETER sort_area_size查，非零即干扰）
最容易被忽略的一点：pga_aggregate_target只是Oracle的“预算基数”，不是硬上限。真实PGA峰值可能达到它的2.5倍（尤其在并行查询场景）。所以即使报告里显示“PGA使用率70%”，也不能排除瞬时过载。
