AWR中无直接PGA使用量指标，需通过DB Time等待占比、direct path read频次、SQL Physical Reads等间接推断；PGA不足表现为DB Time飙升而CPU占比低、direct path read入Top 3、Physical Reads高但Executions低。
PGA使用量在AWR里不直接显示，得靠间接指标推断
AWR报告本身没有“PGA Used MB”这种直白的汇总行。你翻遍Load Profile、Instance Efficiency Percentages甚至Memory Statistics，都找不到这个值。真正能反映PGA压力的，是三个隐藏线索：DB Time中等待事件占比、Top 5 Timed Events里的direct path read和log file sync出现频次，以及SQL ordered by Reads里大量排序/哈希操作的SQL。
常见错误现象：DB Time飙升但CPU占比不高，direct path read排进Top 3，且对应SQL的Executions低但Physical Reads极高——这基本就是PGA不足触发绕过Buffer Cache的直接路径读。
- 查
v$pgastat确认当前会话级PGA峰值：SELECT name, value FROM v$pgastat WHERE name IN ('total PGA allocated', 'total PGA used mem') - 比对AWR快照区间内
PGA_AGGREGATE_TARGET是否被频繁突破（看PGA Memory Advisory部分） - 注意
PGA Cache Hit %低于60%时，说明大量操作被迫落盘，不是缓存没调好，就是单SQL申请过大
从Top SQL定位高PGA消耗语句
在AWR报告的SQL ordered by Gets或SQL ordered by Reads之后，一定要翻到SQL ordered by Physical Reads和SQL ordered by Direct Physical Reads两节。后者才是真正的PGA杀手——它代表SQL绕过SGA，直接把数据读进PGA做排序、哈希、并行中间结果。
使用场景：ETL批量加载、报表聚合、未绑定变量的动态SQL反复执行。这些SQL往往Executions只有1–5次，但Direct Physical Reads动辄上百万，Elapsed Time里70%以上耗在direct path read上。
- 重点看
Module列是否为PL/SQL Developer或sqlplus——人工脚本比应用更爱滥用集合变量 - 检查
SQL Text里是否有ORDER BY、GROUP BY、HASH JOIN、UNION ALL等强内存操作 - 用
DBMS_XPLAN.DISPLAY_AWR查执行计划，确认Operation列是否含TEMP TABLE TRANSFORMATION或SORT AGGREGATE
PL/SQL集合变量不释放是隐形PGA泄漏源
AWR不会告诉你哪个PL/SQL块占了2GB PGA，但v$session和v$process能。如果发现某会话pga_used_mem持续增长且不回落，大概率是TABLE OF VARCHAR2或NESTED TABLE没清理。
容易踩的坑：DELETE方法只是逻辑清空，COUNT变0但内存还在；TRIM或赋值NULL才真正释放。VARRAY还不支持DELETE，强行调用直接报错。
- 监控手段：在PL/SQL块前后执行
SELECT pga_used_mem FROM v$process p JOIN v$session s ON p.addr = s.paddr WHERE s.sid = SYS_CONTEXT('USERENV','SID') - 批量处理必须分块：
BULK COLLECT ... LIMIT 1000+TRIM，别一次性LIMIT 100000 - 避免
DBMS_SESSION.FREE_UNUSED_USER_MEMORY——它对集合变量无效，纯属浪费CPU
PGA_AGGREGATE_TARGET设多大才算合理
不能只看PGA Memory Advisory建议值。Oracle 19c默认启用AUTOMATIC PGA MEMORY MANAGEMENT，但若系统同时跑Java应用或备份进程，PGA_AGGREGATE_TARGET设太高会挤压OS缓存，反而引发SWAP_USED_BYTES上涨。
性能影响关键点：当PGA Cache Hit %稳定在90%以上，且direct path read等待时间占比PGA Cache Hit %在40–60%震荡，PGA_AGGREGATE_TARGET每调高2GB，direct path read应下降15–20%。
- 初始设置参考：专用服务器模式下取物理内存的15–20%，但必须扣减SGA_TARGET和OS预留（至少留4GB给Linux buffer cache）
- 动态调整命令：
ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 8G SCOPE=BOTH，无需重启 - 警惕
PGA_AGGREGATE_LIMIT硬上限：它默认是PGA_AGGREGATE_TARGET * 2，超限直接ORA-04030
真实瓶颈常藏在PL/SQL作用域外——比如一个包体里声明的全局集合变量，整个会话生命周期都不释放。AWR只告诉你“PGA吃紧”，但查不到哪行代码在吃。这时候必须结合v$open_cursor和v$session_longops交叉定位。
