如何使用Oracle AWR诊断PGA内存不足-Oracle-PHP中文网

ora-04030报错后应先定位高内存sql、检查workarea执行模式（optimal/one-pass/multipass）及自动管理是否生效，再验证pga_aggregate_target与pga_aggregate_limit配置是否合理，而非直接调大参数。

如何使用oracle awr诊断pga内存不足

ORA-04030报错后，先别调pga_aggregate_target

ORA-04030 出现时，直接增大 pga_aggregate_target 往往治标不治本。真正要做的，是确认是不是 PGA 真的“不够”，还是某几条 SQL 在疯狂吃内存、或 workarea 预估严重失准。

典型干扰信号包括：sorts (disk)、hash joins (disk) 统计值飙升，但 PGA memory used 总量没爆——说明不是总量缺，而是单次操作分配失败或预估过小。

查 v$pgastat 看 total PGA allocated 是否接近 pga_aggregate_target，但更关键的是看 over allocation count（非零就说明已触发强制扩堆）
运行 SELECT * FROM v$sysmetric WHERE metric_name = 'PGA Memory MBytes'，观察 1 分钟内是否剧烈抖动（>20% 波动），抖动大基本可锁定为 SQL 级别异常
注意：如果 pga_aggregate_limit 被设得太紧（比如仅 3MB × processes），哪怕 pga_aggregate_target 没满，也会因硬限触发 acknowledge over PGA limit 等待事件

从AWR报告里定位“吃内存”的SQL

AWR 的「SQL Statistics → Memory Statistics」页是核心入口，重点盯三列：

Workarea executions – optimal：越高越好，理想应 >95%
Workarea executions – one-pass：>5% 就要警惕，说明部分排序/哈希开始落盘
Workarea executions – multipass：只要非零，必须立即干预——这不是配置问题，是 SQL 或数据倾斜导致 Oracle 低估了所需内存

再往下翻到「SQL ordered by PGA Memory」，直接看到消耗 Top N 的 sql_id。注意这个列表只统计执行时间 ≥1 秒的 SQL，短而猛的内存操作（如单次大排序）可能漏掉，需结合 ASH 补充：

SELECT sql_id, ROUND(SUM(pga_memory_used)/1024/1024, 1) AS pga_mb
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 5 ROWS ONLY;

如果结果为空，检查 DBA_HIST_ACTIVE_SESS_HISTORY 保留策略是否太短（默认 8 天），或 ASH 采样是否被禁用。

Crypto Sniper Oracle

机构级量化市场预言机，提供订单簿失衡（OBI）、VWAP分析、自动化报告及Telegram预警。

下载

确认workarea自动管理是否真在生效

很多 PGA 问题其实源于手动参数残留，让 pga_aggregate_target 形同虚设。

运行 SHOW PARAMETER workarea_size_policy，确保返回 AUTO；若为 MANUAL，立刻改回来：ALTER SYSTEM SET workarea_size_policy=AUTO;
查 SHOW PARAMETER sort_area_size 和 SHOW PARAMETER hash_area_size，二者必须为 0 或 NULL；非零值会强制绕过自动管理
检查是否有 SQL 带 + OPT_PARAM('_smm_max_size' ...) 这类 hint，它会覆盖全局设置，且不会出现在 AWR 的 SQL 文本里，只能靠 SQL Monitor 或 10046 trace 抓