真正有用的是Buffer Pool Advisory中Size Factor偏离1.0时Est Phys Read Factor和Estimated Physical Reads的变化斜率，重点关注物理读骤降的拐点；PGA Memory Advisory需满足Estd PGA Overalloc Count=0且Estd Extra W/A MB Read/Written不再下降；SGA Target Advisory因组件伸缩不均衡常失真，须结合实际负载和内存约束动态调整。
Buffer Pool Advisory里哪几行数据真正有用
只看 size factor = 1.0 对应的那行是没意义的——它只是告诉你“当前设置下物理读是多少”，不提供优化方向。真正要盯的是这三段：从 size factor = 1.0 往上（减小 buffer pool）、往下（增大 buffer pool），观察 est phys read factor 和 estimated physical reads 的变化斜率。
- 往上翻时，如果
Size Factor降到 0.8，Est Phys Read Factor从 1.00 跳到 1.25，说明当前 buffer pool 已经明显冗余，可以安全缩小 - 往下翻时，
Size Factor从 1.0 增到 1.3，但Estimated Physical Reads几乎不变（比如只降了 0.03%），说明再加内存也换不来多少收益，别浪费 - 重点关注拐点：比如从 0.7→0.66 时物理读骤降 15%，而 0.66→0.6 仅再降 0.2%，那
Size Factor = 0.66就是性价比拐点
PGA Memory Advisory中两个硬性判断条件
PGA 建议不是看“越大越好”，而是卡两个底线：Estd PGA Overalloc Count = 0，且 Estd Extra W/A MB Read/ Written to Disk 不再随目标增大而下降。前者代表不会因内存不足被迫临时扩堆，后者代表排序/哈希已基本在内存完成。
- 如果
PGATarget Est (MB)设为 2GB 时Estd PGA Overalloc Count是 12，设为 2.5GB 时变成 0，那就必须 ≥2.5GB —— 否则运行时会频繁触发磁盘溢写 - 若
Estd Extra W/A MB Read/ Written to Disk在 3GB 时是 8.2MB，在 3.5GB 时是 8.19MB，基本持平，说明再往上加 PGA 没实际价值 - 注意：这个建议值受负载影响极大。如果 AWR 报告采样期间跑过一次大报表，
W/A MB Processed会拉高，导致建议值虚高，得结合业务周期人工过滤
SGA Target Advisory为什么经常不准
SGA Target Advisory 的估算逻辑依赖于历史缓存命中行为建模，但它默认假设所有 SGA 组件（buffer cache、shared pool、large pool）按比例伸缩——而现实中，OLTP 系统缺 buffer cache，DSS 系统缺 shared pool，一刀切缩放必然失真。
- 它给出的“最优 SGA Target”可能让
db_cache_size涨了 2GB，但shared_pool_size只涨 200MB，而你的 SQL 解析风暴正需要后者多分 1GB - 当
Library Hit %Cursor: pin S wait on X 等共享池争用等待明显时，宁可手动调大shared_pool_size，也不要迷信 SGA Target 建议的总值 - 检查
V$SGAINFO中各组件实际使用率：Buffer Cache Size使用率长期 Shared Pool Size 使用率 > 95%，就说明 SGA Target 建议分配失衡
别直接抄AWR报告里的“Size for Est”数值
AWR 报告里 Size for Est (M) 是模型反推值，不是推荐配置值。它没考虑 OS 内存预留、其他进程占用、或 Oracle 12c 引入的 memory_target 自动管理冲突。
- 例如报告建议
Buffer Pool = 4.2GB，但你服务器总共才 16GB 内存，OS 需留 2GB，Java 进程占 3GB，Oracle SGA+PGA 总和就不能超 11GB —— 此时 4.2GB 缓冲池可能挤占 PGA 导致排序溢写 - 在 12c 中启用了
memory_target，那sga_target和pga_aggregate_target就是浮动的，直接按 Advisory 固定设死会禁用自动内存管理 - 真实操作顺序应该是：先看 Advisory 找拐点 → 结合
V$MEMORY_DYNAMIC_COMPONENTS观察各组件近期波动范围 → 在总内存约束下做比例再分配，而不是填空式套用
Buffer Pool 和 PGA 的 Advisory 数据本质是“趋势提示器”，不是“配置生成器”。最容易被忽略的是时间维度——单次 AWR 报告只反映采样窗口内的负载特征，而数据库负载往往按日/周波动。拿凌晨批处理时段的 PGA 建议去配白天 OLTP 实例，八成会出问题。
