直接调大db_cache_size在rac大批量导入时无效甚至有害，因direct path write绕过缓存、加剧gc争用、挤压shared_pool引发ora-04031，且buffer cache hit ratio失真；应聚焦physical reads direct占比、gc等待事件及私网mtu等底层瓶颈。
直接调大 db_cache_size 通常没用，甚至会让 rac 更慢——尤其在大批量数据导入场景下。
为什么导入时加 buffer cache 反而拖慢 RAC？
大批量数据导入（如 INSERT /*+ APPEND */、SQL*Loader DIRECT=TRUE）基本不走 default buffer cache：
- 直接路径写（direct path write）绕过 buffer cache，数据块写入文件前不进内存
- 即使走常规插入，RAC 中大量新块会触发频繁的 global cache 资源争用（
gc current block busy、gc buffer busy acquire） -
db_cache_size调太大，会挤压shared_pool_size或large_pool_size，RMAN 备份、日志传输或流复制可能立刻报ORA-04031 - buffer cache hit ratio 在导入期间本就无意义——逻辑读少、物理写多，指标失真
真正该盯住的三个 RAC 内存与等待事件
导入卡顿不是缓存小，而是资源调度和网络瓶颈。重点查：
-
gv$sysstat中physical reads direct和physical writes direct占比：若 >85%，说明几乎全是 direct I/O，调db_cache_size完全无效 -
gv$system_event中等待最高的前 5 项：重点关注gc cr block busy、gc current block busy、enq: TX - row lock contention，这些才是 RAC 导入的真瓶颈 -
gv$memory_dynamic_components各组件实际使用量：确认shared pool是否已逼近min_size，large pool是否被 RMAN 或并行操作吃紧
导入阶段推荐的 buffer cache 相关实操动作
不碰 db_cache_size，改以下几处更有效：
- 关闭
DB_CACHE_ADVICE：ALTER SYSTEM SET DB_CACHE_ADVICE = OFF SCOPE=BOTH;—— 导入期间它徒增 latch 争用 - 禁用结果缓存：
ALTER SYSTEM SET RESULT_CACHE_MODE = MANUAL SCOPE=BOTH;，避免共享池碎片化 - 如有 KEEP/RECYCLE pool，确保导入表段没被意外放在
KEEP池里（ALTER TABLE ... STORAGE (BUFFER_POOL KEEP)是常见误配） - 检查
db_block_buffers是否被旧脚本硬编码：该参数在 11g 已废弃，设了反而干扰db_cache_size自动分配
RAC 私网 MTU 和 GC 消息才是导入吞吐的隐性天花板
大批量导入常伴随高并发 insert 和 block broadcast，GC 消息大小远超默认 MTU=1500：
- 用
ping -M do -s 8972 <other_node_private_ip></other_node_private_ip>测试是否能无分片通达；失败即 MTU 不足 - 确认所有节点私网网卡支持 jumbo frame：
ethtool eth1 | grep "Supports jumbo frames" - 临时生效：
ip link set dev eth1 mtu 9000；永久配置需写入/etc/sysconfig/network-scripts/ifcfg-eth1加MTU=9000 - 同步调大 UDP 缓冲：
net.core.rmem_max=26214400，否则 GC 消息丢包照样卡在gc cr blocks received
Buffer cache 在导入场景里是旁观者，不是主角。真正卡点往往藏在私网 MTU、GC 消息堆积、shared pool 挤压这些容易被忽略的底层联动上。
