缓冲区命中率不能单看数值高低，>95%可能掩盖高逻辑读压力，需结合逻辑读、物理读、等待事件等综合分析内存使用效率。
缓冲区命中率怎么看？别只盯 Buffer Hit Ratio 这个数字
oracle 的 buffer hit ratio（缓冲区命中率）在 awr 报告中常被误读为“越高越好”的黄金指标。实际它只是粗粒度概览，不能单独用来判断内存是否充足。当该值 >95% 时，可能掩盖严重的逻辑读压力；而
真正要关注的是：为什么没命中？是物理读太多，还是逻辑读爆炸？
-
Physical Reads高 +Logical Reads正常 → 确实可能缺db_cache_size -
Logical Reads异常高（比如单 SQL 占比超 30%）→ 先优化 SQL，不是加内存 -
DB Block Gets和Consistent Gets比例突变 → 可能存在热点块争用或事务设计问题
从 AWR 报告里抓关键内存相关指标的路径
打开 AWR 报告后，直接跳到「Instance Efficiency Percentages」部分，这里列出的几个百分比都和内存使用强相关，但含义各不相同：
-
Buffer Nowait %：表示进程尝试获取 buffer 时不等待的比例。低于 99% 就要警惕，说明存在 buffer busy waits，可能因缓存太小或热点块导致 -
Redo Nowait %：和 log buffer 有关，持续 log_buffer（但通常不建议盲目调大，先看redo allocation retries） -
Shared Pool Free %：不在主报告里，需查「Shared Pool Statistics」子节。若长期 library cache hit ratio 也可能同步下降
注意：Buffer Hit Ratio 是加权平均值，对短周期突发性 I/O 不敏感。建议结合「Top 5 Timed Foreground Events」看是否有 db file sequential read 或 db file scattered read 排在前两位。
用 AWR 数据反推 db_cache_size 是否合理
AWR 本身不直接给出“该设多大”，但可通过两个视图交叉验证当前设置是否匹配负载：
- 查
dba_hist_sgastat中buffer_cache的历史占用峰值（按 snapshot_id 排序），对比当前db_cache_size：若峰值长期达 95%+ 且伴随free buffer waits，说明缓存吃紧 - 运行
SELECT * FROM v$db_cache_advice;（需db_cache_advice = ON）——这是最接近“评估建议”的功能。重点看size_for_estimate对应的estd_physical_read_factor：若从 1024M 增到 2048M 能让 factor 从 1.2 降到 1.05，说明有收益；若降到 1.01 以下，再加意义不大
注意：v$db_cache_advice 的估算基于历史 workload 模型，对新上线的大表扫描类应用不适用。上线前务必用真实 SQL 做 buffer pool 测试。
容易被忽略的内存竞争点：in-memory area 和 pga_aggregate_target
12c 及以后版本启用 inmemory_size 后，db_cache_size 不再是唯一瓶颈。AWR 中「Memory Statistics」节会显示 In-Memory Area Used 和 In-Memory Area Free。如果 free 长期 Buffer Hit Ratio 很高，也可能因压缩失败或 segment 无法入内存导致性能抖动。
同样，pga_aggregate_target 不足不会降低命中率，但会把 sorts (disk) 推高，在 AWR 的「Load Profile」里表现为 PGA Memory 使用率 >90%、同时 SQL*Net message from client 等待上升——这其实是内存不足引发的 I/O 衍生等待。
这类问题不会在缓冲区命中率里暴露，但会在「SQL ordered by Reads」或「SQL ordered by Physical Read Bytes」里暴露 Top SQL 的 physical read bytes 异常高，此时翻看执行计划，大概率看到 TEMP TABLESPACE 或 USING TEMP 字样。
