V$PGA_TARGET_ADVICE不准因非实时工具，需满足三前提才可信：缓存命中率长期<85%且over allocation持续增长、ADVICE_STATUS为ENABLED、实例稳定运行一个完整负载周期。
PGA Aggr Target Advice 为什么不准？先看它有没有资格说话
这个视图不是实时诊断工具，而是基于实例启动以来 v$pgastat 累积数据做的趋势推演。刚重启的库、跑不满一个业务高峰的库，v$pga_target_advice 里全是空值或抖动数据——这时候查它，等于拿天气预报去判断此刻要不要打伞。
真正能信它的前提有三个：
-
cache hit percentage在v$pgastat中长期低于 85%，且over allocation count持续上涨 -
ADVICE_STATUS字段是ENABLED（隐含参数或内存严重不足时可能被自动禁用） - 实例已稳定运行至少一个典型负载周期（比如白天交易高峰+夜间批量）
执行 SELECT * FROM V$PGA_TARGET_ADVICE WHERE pga_target_factor = 1;，如果命中率预估只有 72%，而你当前 pga_aggregate_target 是 4G，那说明这 4G 已经撑不住了；但如果显示 96%，再往下翻几行发现 ESTD_EXTRA_BYTES_RW 是 0，那就别加了——降配都影响不大。
AWR 报告里哪几行直接暴露 PGA 卡脖子
别只盯着「PGA Aggr Target Stats」小节。真正致命的信号藏在更靠前的位置：
- 「SQL Statistics → SQL ordered by Physical Read Bytes」：排在前面的 SQL，大概率正在疯狂写
temp表空间，但未必计入sorts (disk) - 「Workarea Executions – optimal / one-pass / multipass」这一行：只要
multipass非零，就是硬伤；超过 5% 就得动手 - 「Top SQL with Top Memory Usage」点开后看单条 SQL 的
ACTUAL_MEM_USED和WORK_AREA_SIZE：差 3 倍以上，说明 Oracle 强制把它踢到磁盘做了
另外注意：如果 AWR 里 sorts (disk) 不高，但 direct path write temp 等待事件飙升，问题可能出在哈希连接、位图合并或物化视图刷新上，不是排序本身。
ORA-04030 和 ORA-04036 不是一回事，别混着调
ORA-04030 是进程级内存耗尽，常伴随大量 sorts (disk) 和 hash joins (disk)；ORA-04036 则是实例级熔断，触发条件是 PGA 总用量突破 PGA_AGGREGATE_LIMIT——这个参数默认是 2 × pga_aggregate_target 或 2G，取大者。
常见误操作：
- 看到
ORA-04036就去调大pga_aggregate_target：错。它可能根本没到 limit 就被卡死了 - 执行
ALTER SYSTEM SET PGA_AGGREGATE_LIMIT = 0临时绕过：能跑，但等于拆掉保险丝，下次可能直接宕机 - 忽略绑定变量缺失：几十个字面量不同的 SQL 各自分配工作区，
v$process里PGA_USED_MEM加起来爆表，但单条 SQL 看不出异常
调参前必须确认 workarea_size_policy 是否真生效
Oracle 10g 起默认启用自动 PGA 管理，但手动干预会悄悄让它失效：
- 查
SHOW PARAMETER workarea_size_policy：必须是AUTO（默认值，但有人会显式改成MANUAL） - 查
SHOW PARAMETER sort_area_size和hash_area_size：这两个值必须为 0，否则自动管理被绕过 - 检查 SQL 中是否带
+ OPT_PARAM('_smm_max_size' 'xxx')这类 hint：它会覆盖全局策略
如果发现 sort_area_size 非零，哪怕你把 pga_aggregate_target 设成 20G，sorts (disk) 也不会少——因为 Oracle 根本没用它。
最易被忽略的点：OLTP 系统盲目堆高 pga_aggregate_target，会挤占 db_cache_size，导致 buffer cache hit ratio 下跌、逻辑读飙升，最后 CPU 更高、响应更卡。调参不是填空题，是资源再平衡。
