AWR报告中sorts(disk)/sorts(memory)>5%即表明PGA不足，需调pga_aggregate_target；应查v$pga_target_advice视图按负载历史精准估算，并确保workarea_size_policy=AUTO。
awr 报告里看到大量 sorts (disk)，说明排序正在频繁写临时表空间——这不是靠改 sql 就能解决的，得调 pga_aggregate_target。
怎么看 AWR 里排序是否成瓶颈
打开 AWR 报告，在「Instance Activity Stats」部分找这两行：
-
sorts (memory)：纯内存完成的排序次数 -
sorts (disk)：溢出到临时表空间的排序次数
如果 sorts (disk) / sorts (memory) > 5%，基本可以断定 PGA 不够用。别只看单次 SQL 的执行计划——AWR 统计的是整个采样周期的累积行为，更反映真实负载。
补充查法：SELECT * FROM v$pgastat WHERE name = 'cache hit percentage';，低于 95% 就该警惕了。
为什么不能直接调 sort_area_size
Oracle 10g 起默认启用自动 PGA 管理，workarea_size_policy 是 AUTO，此时手动设 sort_area_size 会被忽略。强行设成 MANUAL 反而会破坏 Oracle 对不同工作区（排序、哈希、位图合并）的动态分配逻辑。
常见错误现象：ALTER SYSTEM SET sort_area_size=209715200; 执行成功，但 v$sysstat 里的磁盘排序数毫无变化——因为参数没生效。
正确做法：只动两个参数：pga_aggregate_target 和确保 workarea_size_policy = AUTO（后者通常是默认值，查一下就行）。
怎么从 AWR 数据反推合适的 pga_aggregate_target
别拍脑袋设值。用 Oracle 自带的预测视图：
SELECT ROUND(pga_target_for_estimate/1024/1024) AS mb,
estd_pga_cache_hit_percentage AS hit_pct,
estd_overalloc_count
FROM v$pga_target_advice
ORDER BY mb;
这个结果告诉你：如果把 pga_aggregate_target 设为 2GB，预估缓存命中率是 92%，超分配次数是 3；设为 4GB，命中率升到 98%，超分配归零——那就优先选 4GB。
注意三点：
- 该视图数据基于当前负载历史生成，必须等数据库跑过至少一个典型业务周期（比如白天高峰后）再查才准
-
pga_aggregate_target建议不超过物理内存的 50%，OLTP 系统通常 20%–30% 更稳 - 改完要观察 24 小时，重点看
v$pgastat的total PGA allocated是否持续逼近设定值，以及over allocation count是否归零
临时表空间暴增但 sorts (disk) 不高？可能是其他操作在用
别一见临时表空间使用率飙升就认定是排序。以下操作同样走临时表空间，但不计入 sorts (disk) 统计：
-
HASH JOIN中哈希表构建失败回退到磁盘 -
GROUP BY或DISTINCT使用哈希聚合而非排序聚合 - 并行查询中各进程的中间结果合并
这时看 v$sysstat 里 hash joins、hash join buffer space 相关指标，或直接查 v$sort_segment 的 max_used_blocks 是否突增。单纯加 pga_aggregate_target 可能治标不治本。
真正难调的不是数值本身，而是确认那个「典型业务周期」到底多长——有些批处理作业每周只跑一次，AWR 必须覆盖它才能给出靠谱建议。
