如何分析AWR中的PGA建议_PGA Target Advisory与排序区不足排查-Oracle-PHP中文网

v$pga_target_advice可信需满足：实例运行足够久、v$pgastat中缓存命中率长期

怎么看 v$pga_target_advice 是否可信

它不是实时采样结果，而是基于实例启动以来 v$pgastat 累积的 pga 使用模式做的预测。所以刚重启的库，这个视图里数据基本是空的或不准——别急着调参。

判断是否可用，先查 V$PGASTAT 的 total PGA allocated 和 cache hit percentage：如果命中率长期低于 85%，且 over allocation count 在涨，说明当前 PGA_AGGREGATE_TARGET 确实偏小，V$PGA_TARGET_ADVICE 的建议才有参考价值。

执行 SELECT * FROM V$PGA_TARGET_ADVICE WHERE pga_target_factor = 1;，看当前配置下的预估命中率是否明显低于 90%
检查 ESTD_EXTRA_BYTES_RW（预估额外物理读字节数）：值越大，说明降配风险越高；若为 0，说明再降也影响不大
注意 ADVICE_STATUS 字段：必须是 ENABLED，否则顾问功能被禁用（可能因隐含参数或内存不足触发自动关闭）

怎么从 AWR 报告里快速定位排序区不足

AWR 报告中 “PGA Aggr Target Stats” 小节直接来自 V$PGA_TARGET_ADVICE，但真正暴露问题的，是 “SQL Statistics” → “SQL ordered by Reads” 或 “SQL ordered by Physical Read Bytes” 里的语句——它们往往正在大量使用磁盘临时段做排序/哈希连接。

关注 “Workarea Executions – Optimal / One-Pass / Multi-Pass” 这一行：如果 Multi-Pass 占比 >5%，基本可断定排序区严重不足
“PGA Cache Hit %” 低于 80% 是红色信号；低于 70% 通常伴随大量 direct path write temp 和 direct path read temp 等待
别只盯平均值——点开 “Top SQL with Top Memory Usage” 查看单条 SQL 的 WORK_AREA_SIZE 和实际使用的 ACTUAL_MEM_USED，差几倍就说明该 SQL 被强制降级到磁盘了

为什么调大 PGA_AGGREGATE_TARGET 反而更慢

不是所有场景都适合加 PGA。OLTP 类业务如果盲目把 PGA_AGGREGATE_TARGET 设到 20G+，反而会挤占 SGA，导致 db cache hit ratio 下跌、逻辑读飙升，最终 CPU 更高、响应更卡。

确认业务类型：OLTP 建议 PGA_AGGREGATE_TARGET ≤ (total_mem × 0.8) × 0.2；DSS/报表类才考虑均分
检查 PGA_AGGREGATE_LIMIT：它默认是 2GB 或 200% × PGA_AGGREGATE_TARGET，取大者。如果进程频繁报 ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT，说明不是 target 小，而是 limit 卡死了
临时缓解可用 ALTER SYSTEM SET PGA_AGGREGATE_LIMIT=0 SCOPE=BOTH;，但这只是关掉熔断器，不解决根本问题

排查时最容易漏掉的两个点

一个是绑定变量缺失导致的硬解析风暴——每个不同字面量的 SQL 都单独分配 PGA 工作区，汇总看 V$PROCESS 里 PADDR 对应的 PGA_USED_MEM，你会发现几十个进程各自占了几百 MB，但没一个超限；另一个是 PL/SQL 数组批量操作，比如 BULK COLLECT INTO 没限制 LIMIT，一次拉几百万行进 PGA，瞬间打爆。

查异常 PGA 消耗会话：SELECT pid, spid, program, pga_used_mem/1024/1024 mb FROM v$process ORDER BY pga_used_mem DESC FETCH FIRST 5 ROWS ONLY;
查当前活跃大工作区：SELECT sql_id, operation_type, policy, actual_mem_used/1024/1024 mb FROM v$sql_workarea_active WHERE actual_mem_used > 100*1024*1024;
V$SQL_WORKAREA_HISTOGRAM 里的 LOW_OPTIMAL_SIZE 和 HIGH_OPTIMAL_SIZE 范围，能告诉你大多数排序操作“本来想吃多少”，而不是“被迫吃了多少”

真正难的不是看懂数字，是把 V$PGA_TARGET_ADVICE 的百分比变化，和某次业务发布后多出的三条 SQL、两个未加 /*+ USE_HASH */ 的关联、或者 DBA 误删了 pga_aggregate_target 的历史快照，一一对应上。