拐点是pga_target_for_estimate增加时estd_pga_cache_hit_percentage不再明显上升或estd_overalloc_count显著下降的位置，即当前负载下最经济的PGA_AGGREGATE_TARGET下限；estd_overalloc_count比hit ratio更敏感，能揭示长尾大查询的磁盘排序问题。
怎么看 v$pga_target_advice 里的关键列
直接查 v$pga_target_advice 不是目的，重点是识别“拐点”：当 pga_target_for_estimate 增加时，estd_pga_cache_hit_percentage 不再明显上升，或 estd_overalloc_count 开始显著下降的位置。这个拐点往往就是当前负载下最经济的 PGA_AGGREGATE_TARGET 下限。注意 estd_overalloc_count 是预估的 PGA 内存超分配次数（即实际需要 > 当前设定值），它比 hit ratio 更敏感——即使 hit ratio 看似稳定在 92%，只要 estd_overalloc_count 从 0 跳到几百，就说明部分大查询已在频繁触发磁盘排序。
为什么不能只看 “Cache Hit % > 90%” 就停手
v$pga_target_advice 的 hit ratio 是全局加权平均，掩盖了长尾影响。常见陷阱包括：
- OLTP 类会话占多数，但几个报表 SQL 占用 80% 的 PGA 需求，它们的排序已 spill 到磁盘，却拉低不了整体 hit ratio
-
estd_pga_cache_hit_percentage在 1.5G → 2G 区间从 89% → 91%，看似提升不大，但对应estd_overalloc_count从 127 → 0 —— 这 500MB 就是关键阈值 - 启用并行（
DEGREE > 1）后，单个 SQL 的 workarea 需求呈倍数增长，而v$pga_target_advice默认按串行模型估算，容易低估
结合 AWR 定位真实瓶颈 SQL 再反推 PGA 需求
光调 PGA_AGGREGATE_TARGET 不解决具体 SQL 的排序抖动。必须联动查 AWR：
- 跑
SELECT * FROM dba_hist_sqlstat WHERE sql_id IN (SELECT sql_id FROM dba_hist_sql_plan WHERE operation = 'SORT') ORDER BY temp_space_allocated DESC找出真实占用临时表空间最多的 SQL - 对这些 SQL 执行
EXPLAIN PLAN FOR ...，看执行计划中SORT操作的BYTES和COST列，再对比v$sql_workarea中该 SQL 实际使用的actual_mem_used和max_mem_used - 如果某 SQL 的
max_mem_used接近 200MB，而你设的PGA_AGGREGATE_TARGET是 2G，那它理论上可分到约 400MB（按 Oracle 默认 20% 分配策略），但它仍 spill，大概率是统计信息不准或存在隐式转换，得重写 SQL，而不是继续加 PGA
调完之后必须验证的两个动作
改完 PGA_AGGREGATE_TARGET 后别以为万事大吉：
- 立刻查
v$pgastat，确认cache hit percentage是否真实上升，且bytes processed/bytes cache hits的比值收敛 —— 这个比值突然变大，说明新 PGA 没被有效利用，可能被少数大查询独占 - 观察
v$sort_segment的max_sort_blocks是否下降：如果它没变，说明仍有 SQL 在走磁盘排序，只是总量少了；如果它反而升高，说明某条 SQL 的排序量变大了，可能是执行计划变更导致
真正卡住性能的，往往不是 PGA 总量不够，而是某条 SQL 的排序路径失控 —— v$pga_target_advice 只告诉你“大概要多少”，不告诉你“哪条在捣乱”。
