Buffer Hit Ratio高不等于内存够用，本质是逻辑读分布失衡；需结合Physical Reads、Logical Reads、DB Block Gets/Consistent Gets三指标交叉验证，并参考v$db_cache_advice拐点及SGA组件争用情况。
Buffer Hit Ratio高≠内存够用，本质是逻辑读分布失衡
oracle 11g中buffer hit ratio在awr报告的「instance efficiency percentages」里常显示98%甚至99%，但这不说明db_cache_size设置合理。它只是加权平均值，对短周期突发性i/o不敏感——比如某张大表每小时被扫描一次，其余时间全走缓存，命中率照样虚高。真正的问题藏在「为什么没命中」：是物理读太多？还是逻辑读爆炸？
典型误判场景：Buffer Hit Ratio >95% 但 db file sequential read 在Top 5 Timed Events里排第一，且平均等待时间>10ms。这说明缓存只留住了最热的几块数据，冷数据一查就打盘，高命中率反而掩盖了I/O压力。
必须交叉验证的三个物理IO指标
单看Buffer Hit Ratio毫无意义，要结合以下三项定位真实瓶颈：
-
Physical Reads高 +Logical Reads正常 → 缓存确实不足，优先检查db_cache_size是否被其他SGA组件挤压 -
Logical Reads异常高（例如单条SQL占总逻辑读30%以上）→ 先优化SQL，加索引或改写，不是盲目扩内存 -
DB Block Gets与Consistent Gets比例突变（如后者骤增）→ 可能存在热点块争用或事务设计问题，buffer busy waits会同步上升
v$db_cache_advice才是接近“建议值”的工具
v$db_cache_advice基于历史workload建模，能估算不同db_cache_size下的estd_physical_read_factor。但要注意：
- 需先确保
db_cache_advice = ON（默认ON，但某些11g补丁后可能被重置） - 结果只对已有负载有效；新上线的大表扫描类应用，该视图完全不适用
- 重点看拐点：若从1024M增到2048M让
estd_physical_read_factor从1.2降到1.05，有收益；降到1.01以下，再加意义不大
容易被忽略的底层竞争：in-memory area和PGA抢占SGA
11g虽无In-Memory Option，但inmemory_area参数若被手动设过（尤其升级后残留），会静态占用SGA空间，挤压db_cache_size。同时pga_aggregate_target过大也会间接导致SGA可用内存减少——因为Oracle 11g的自动内存管理（AMM）在Linux上实际效果有限，更依赖手工分配。
查证方法：SELECT component, current_size FROM v$sga_dynamic_components WHERE component IN ('DEFAULT buffer cache', 'shared pool'); 若当前值长期低于初始化参数设定值，说明内存被其他组件动态抢走了。
