Oracle RAC 是什么？它解决了什么问题？

简化版

Oracle RAC 是 Real Application Clusters，允许多个数据库实例同时访问同一个数据库，通常基于共享存储，用来提升高可用和横向扩展能力。一个节点故障时，其他节点仍可继续提供服务。RAC 不是简单把单机性能线性放大，多节点之间需要缓存一致性和全局资源协调，应用设计也要考虑热点数据和事务分布。

详细版

RAC 的核心特点：

多个实例访问同一套数据库文件；
每个实例有自己的 SGA 和后台进程；
底层使用共享存储；
通过集群件协调节点、资源和故障；
通过缓存融合等机制维护多实例缓存一致性；
常用于核心交易系统高可用。

RAC 适合对可用性要求极高、单实例故障不可接受的场景。但它也带来架构复杂度、运维成本、跨实例通信开销和热点块争用问题。

完整版教学

一、RAC 和单实例的区别

普通 Oracle 单实例结构是一个实例访问一个数据库。实例包括内存和后台进程，数据库是磁盘上的数据文件、控制文件、日志文件等。

RAC 则是多个实例共同访问同一个数据库：

Instance 1  \
Instance 2   -> Shared Database Files
Instance 3  /

每个实例都能接受连接和执行 SQL，但它们面对的是同一份数据。

二、RAC 主要解决高可用

如果单实例宕机，数据库服务会中断。RAC 中某个节点故障时，其他节点仍可工作，业务可以通过服务和连接配置切到存活节点。

这对银行、电信、核心交易等场景很重要，因为这些系统不能轻易接受单点故障。

不过高可用不等于永不出问题。存储、网络、集群件、应用连接池配置都可能影响最终可用性。

三、RAC 也能扩展但不是线性扩展

多个实例可以分担连接和 SQL 执行压力，所以 RAC 有一定扩展能力。但它不是“加一台机器性能就翻倍”。

原因是多个实例访问同一份数据，需要维护缓存一致性。如果实例 A 修改了某个数据块，实例 B 又要读这个块，就涉及跨节点协调。

热点数据频繁在节点间争用，会带来性能损耗。

四、缓存融合为什么重要

RAC 中每个实例都有自己的 Buffer Cache。为了避免不同实例看到不一致的数据，Oracle 需要全局协调数据块状态。

缓存融合可以在实例之间传递数据块，减少直接读共享存储的开销。但跨节点传输仍然比本地内存访问更贵。

所以 RAC 优化常常要关注：

热点块；
事务是否跨节点争用同一批数据；
服务是否按业务分布到合适节点；
序列、索引右端增长热点；
interconnect 网络性能。

五、应用使用 RAC 要注意什么

应用层不能只把 RAC 当成普通数据库地址池。要考虑：

连接负载均衡；
节点故障后的连接重连；
事务重试；
服务按业务模块隔离；
避免所有节点争抢同一热点数据；
批处理任务不要无脑多节点同时打满。

RAC 提供强大的基础设施，但应用和运维也要配合设计。

六、常见误区与追问

能力	RAC 的价值	需要付出的代价
高可用	单节点故障后其他节点继续服务	集群件、存储、网络都要可靠
扩展连接和部分负载	多实例分担 SQL 执行	热点块会跨节点争用
统一数据库	多实例访问同一份数据	全局缓存一致性开销

记忆钩子：RAC 先是高可用方案，再谈扩展能力。它不是“多加节点就线性提速”，跨实例缓存一致性才是面试追问重点。

举个热点块例子：一个订单号序列或索引右端块被 3 个实例同时高频写入，每秒 1 万次插入都争用相近数据块。节点越多，数据块状态在实例间传递越频繁，interconnect 压力和等待事件可能上升。这类场景需要从服务分布、序列/索引设计、业务分片和热点隔离上优化，而不是盲目加节点。

误区：RAC 可以让数据库性能按节点数线性增长。 多实例有协调成本，热点数据和跨节点通信会限制扩展效果。
误区：RAC 只要数据库层配置好，应用不用改。 应用连接池、重连、服务路由、事务重试和业务热点都要配合。
误区：共享存储有了 RAC 就没有单点风险。 存储、网络、集群件、仲裁和运维流程仍然是高可用链路的一部分。
追问：缓存融合解决什么？ 它维护多个实例 Buffer Cache 中数据块的一致性，并尽量通过实例间传块减少直接读盘。
追问：RAC 适合什么业务？ 对数据库可用性要求极高、单实例故障不可接受、愿意承担复杂运维成本的核心系统。
追问：RAC 性能排查关注什么？ 热点块、全局缓存等待、interconnect、服务分布、SQL 访问模式、序列和索引右端热点。

七、加强记忆

Oracle RAC 记住“多实例、同数据库、共享存储、高可用”。它能提高可用性，也能分担压力，但不是线性扩容神器；多实例之间要维护缓存一致性，热点块和跨节点争用是 RAC 性能面试的关键。

简化版

详细版