estd_physical_reads突降表明db_cache_size越过临界点后物理读边际收益锐减，应选取拐点后斜率趋平的性价比最优档位，并确认其符合granule size对齐要求且size_factor≥1.0。
AWR 报告里没有“内存配置是否合理”的直接结论，但能通过几组关键指标交叉验证当前 db_cache_size、shared_pool_size 和 pga_aggregate_target 是否匹配真实负载——关键是看“变化趋势”和“边际收益”，不是单看某个数字高低。
Buffer Cache Advisory 的 ESTD_PHYSICAL_READS 突降说明什么
这不是“缓存变好了”的信号，而是预估物理读下降趋势出现拐点的提示。突降通常发生在某档 SIZE_FOR_ESTIMATE 刚越过临界值（比如从 4G → 6G），再往上加 db_cache_size 对减少物理读的收益已急剧衰减。
- 别只盯着最低点：找
ESTD_PHYSICAL_READS从 12000 → 11800 → 11795 这种后两档几乎不变的区间，前一档就是性价比最优档位 - 确认该档尺寸是否满足 Granule Size 对齐：查
V$SGAINFO中Granule Size，若为 4MB，而建议值是 5.3GB，则实际生效的是 5.2GB 或 5.6GB，得手动对齐 - 过滤掉无效行：检查对应行的
SIZE_FACTOR必须 ≥ 1.0；小于 1 是降级模拟，不能当扩容依据
Shared Pool Advisory 不能代替 Library Hit % 判断
Shared Pool Advisory 不输出命中率，它只估算不同 shared_pool_size 下能多缓存多少库对象、节省多少解析时间。真正反映硬解析压力的是 Library Hit %，必须回看 AWR 中「Instance Efficiency Percentages」部分。
- 若
Library Hit %V$SQL 中大量 SQL 的version_count> 1，优先排查未绑定变量、SQL 文本不规范等问题，不是盲目调大shared_pool_size -
V$SGASTAT中free memory在 shared pool 下持续低于 100MB，才说明内存真吃紧；短期波动（如 500MB ⇄ 50MB）更可能是 ASMM 动态 resize 引入非大页内存 - 调大
shared_pool_size后parse time elapsed反而上升，大概率是新增内存段没落入大页——需结合/proc/<pid>/maps</pid>验证
PGA Memory Advisory 的 Est PGA Overalloc Count > 0 就要干预
只要 V$PGA_TARGET_ADVICE 或 AWR 中「PGA Memory Advisory」表格里，任意 SIZE_FACTOR ≥ 1.0 行的 Est PGA Overalloc Count > 0，就说明当前 pga_aggregate_target 不足以支撑峰值负载，部分排序/Hash Join 已溢出到 temp 表空间。
- 同步检查
V$SQL_WORKAREA_ACTIVE：若ACTUAL_MEM_USED频繁接近甚至超过WORK_AREA_SIZE，说明单条 SQL 正在突破预估上限 - 确认
workarea_size_policy = AUTO，且没被 session 级sort_area_size覆盖——否则pga_aggregate_target形同虚设 - 如果
Workarea executions – multipass非零，不是调大 PGA 就能解决，得查是不是 SQL 写法导致 workarea 预估严重失准（如缺少统计信息、谓词失真）
Instance Efficiency Percentages 里的 Buffer Nowait % 低于 99% 就危险
Buffer Nowait % 是比 Buffer Hit Ratio 更敏感的指标：它反映进程尝试获取 buffer 时是否立即成功。低于 99% 就意味着存在可观的 buffer busy waits，可能由缓存不足、热点块争用或事务设计问题引发。
-
Buffer Hit Ratio> 95% 但Buffer Nowait %持续 97% → 说明逻辑读爆炸，先查「SQL ordered by Logical Reads」，不是加内存 -
Redo Nowait %持续下滑，配合log_buffer无明显增长，可能是大页碎片或缺失，需查 OS 层HugePages_Free和/proc/<pid>/maps</pid> -
DB CPU排 Top 2 且Physical Reads未升，同时latch: shared pool等待陡增，大概率是 TLB miss，这时调内存治标不治本，得开大页
最易被忽略的点是：所有 Advisory 视图都基于历史 workload 模型，对刚上线的大表扫描类 SQL 或突发性内存消耗（如临时大排序）完全不敏感。上线前必须用真实负载跑 buffer pool 和 workarea 压测，不能只信 AWR 里的“建议值”。
