Oracle RAC中db_cache_size是实例级参数，各节点独立配置且不共享缓存；调优需结合gc等待、私网质量及内存分配均衡性，而非盲目增大。
Oracle RAC中db_cache_size不是全局统一设置的
很多人以为在rac里把db_cache_size设成一个值，所有实例就自动共享同一块缓存——这是错的。rac里每个实例都有自己的db_cache_size，它们各自管理本地sga中的缓冲区，不跨节点共享数据块缓存（缓存融合靠cr和current块传输，不是共享内存）。所以调高某一个实例的db_cache_size，只影响该实例的本地缓存命中率，对其他实例无直接帮助。
常见错误现象：DB CPU高、gc buffer busy acquire等待陡增、global cache cr block receive time变长——这些往往不是因为缓存太小，而是因为缓存局部性差或块争用激烈。
- 检查各实例实际使用的缓存大小：
SELECT inst_id, component, current_size FROM gv$memory_dynamic_components WHERE component = 'DEFAULT buffer cache'; - 确认是否启用了
automatic memory management (AMM)：如果开了memory_target，手动设db_cache_size可能被忽略，优先查gv$memory_target_advice - RAC建议用
db_cache_size而非db_block_buffers（后者是旧参数，不支持动态调整）
调整前必须看buffer cache hit ratio是否真低
“运行慢就加缓存”是典型误区。buffer cache hit ratio低于90%才值得怀疑，但低于85%才真正提示缓存压力；而RAC中这个指标本身有误导性——它不区分本地访问和远程获取的块。一个实例可能hit ratio 95%，但其中30%的“命中”其实是从其他实例内存里拉来的CR块，这不算真正高效。
更关键的指标是：physical reads（尤其是physical reads direct）、gc cr blocks received与gc current blocks received的比值、以及free buffer waits是否持续非零。
- 查真实缓存效率：
SELECT inst_id, name, value FROM gv$sysstat WHERE name IN ('db block gets', 'consistent gets', 'physical reads');然后手工算：(db block gets + consistent gets − physical reads) / (db block gets + consistent gets) - 如果
physical reads direct占比高，说明大量全表扫描绕过了缓存，调db_cache_size没用，得优化SQL或加索引 - 若
gc current blocks received远高于gc cr blocks received，说明写热点集中，加缓存反而加剧全局锁争用
db_cache_size调太大反而引发ORA-4031和内存抖动
RAC节点间SGA分配不均时，盲目增大db_cache_size会挤压共享池（shared_pool_size）或大池（large_pool_size），尤其当使用了RMAN备份、流复制或高级队列时，shared_pool不足会直接触发ORA-04031: unable to allocate X bytes of shared memory。
另一个问题是Linux下vm.swappiness=1未配置，导致Oracle SGA页被内核交换出去，表现为read by other session等待飙升、v$sgastat中free memory忽高忽低。
- 单实例SGA建议上限：不超过物理内存的60%；RAC双节点建议总和不超过物理内存的75%，且两节点
db_cache_size尽量对称（差异＞20%易引发负载倾斜） - 调整后必做：
ALTER SYSTEM FLUSH BUFFER_CACHE（仅测试环境），生产环境改完观察15分钟内gv$sga_dynamic_components是否稳定，避免dynamic_sga反复收缩/扩张 - 检查
/proc/meminfo中MemAvailable是否持续＜2GB——这是内存过载的硬信号
真正影响RAC缓存效率的其实是_gc_policy_time和cache fusion网络
很多DBA花半天调db_cache_size，却忽略两个更关键的点：一是Oracle默认每3秒做一次全局缓存策略重评估（由隐含参数_gc_policy_time控制），频繁重平衡会导致gc remastering开销；二是私网延迟＞1ms或丢包率＞0.1%，cache fusion性能断崖式下跌，此时加再多缓存也白搭。
典型表现：gc current block 2-way等待时间突增、gc cr block build time超过10ms、top里oracle进程CPU集中在kgxgnc或kjbr函数上。
- 验证私网质量：
ping -c 10 -s 8192 node2_private_ip（用8KB包模拟cache fusion流量），丢包或延迟＞2ms需排查网卡驱动、MTU、交换机QoS - 临时降低重平衡频率（谨慎）：
ALTER SYSTEM SET "_gc_policy_time"=30 SCOPE=SPFILE SID='*';，重启后生效，但可能延长块主控权迁移响应时间 - 确认是否启用了
infiniband或RDS协议：若私网是千兆以太网，tcp.nodelay=1和net.core.somaxconn=65535必须设置，否则gc吞吐量卡死在~80MB/s
缓存大小只是RAC性能拼图的一小块，真正卡脖子的往往是私网稳定性、块主控分布、以及SQL是否天然适合分布式执行——这些地方一出问题，调db_cache_size就像给漏水的桶拼命加水。
