Oracle RAC 走过 25 年：架构没变，战场已经变了

2026 年 8 月 3 日Oracle MAA 团队发了一篇回顾文章纪念 Oracle RAC 推出 25 周年。做过 Oracle 的人对这条产品线大多不陌生。从 9i、10g、11g 到 19cRAC 几乎贯穿了大型 Oracle 系统的建设周期。它也留下过不少让 DBA 头疼的现场脑裂、节点驱逐、私网抖动、GC 等待、服务漂移以及凌晨变更窗口里迟迟不敢落下的那条命令。所以25 周年没必要只回顾版本号。更值得看的是 RAC 解决问题的方式有没有变化以及云和 AI 把它带到了什么位置。RAC 最初要解决的问题今天仍然存在Oracle 把 RAC 的起点放在 2001 年。目标并不复杂一个数据库实例或一台服务器发生故障时数据库服务不能跟着全部停掉业务增长时也不应该只能更换一台更大的主机。RAC 的基本办法是让多个实例运行在不同服务器上同时访问同一个数据库。应用连接的是逻辑服务不需要感知自己最终落在哪个实例。实例之间通过私有互联交换缓存块Clusterware 管理节点、实例和服务ASM 负责共享存储。这套设计里最重要的并不是“集群”两个字而是把数据库实例从单机故障域里拆了出来。坏掉一个实例其他实例还能继续提供服务容量不足时可以增加节点和实例而不是先安排一次整体停机。Oracle 后来陆续加入 Cache Fusion、ASM 和 Application Continuity。它们处理的层次不同Cache Fusion 负责实例间缓存一致性ASM 管理共享存储Application Continuity 则尝试在计划内维护或意外中断后重放可重放的数据库请求减少故障直接暴露给应用。RAC 从来不等于“不会出故障”。它做的是缩小故障影响提供继续服务和恢复工作的条件。能否把这些能力真正用起来还取决于服务配置、连接池、事务特征、故障检测以及应用是否满足重放条件。版本在变主线一直围绕可用性和可扩展性Oracle 在回顾中列出了几次主要版本变化。版本主要变化对 DBA 的影响9i RACRAC 产品线起点多实例访问单一数据库成为标准方案10gOracle Clusterware 成为 RAC 基础集群资源管理逐步进入 Oracle 自己的技术栈11g Release 2Clusterware 与 ASM 统一到 Grid Infrastructure安装、补丁、存储和集群运维联系得更紧12c引入 Application Continuity高可用开始从数据库实例延伸到应用请求19c新一代 RAC长期支持版本成为许多生产系统的稳定落点23ai / 26ai支持 AI Vector Search并面向企业 AI 工作负载扩展RAC 开始承载传统交易与 AI 数据访问的混合需求把这些版本放在一起看会发现 RAC 并没有频繁更换核心模型。Oracle 一直在补齐外围能力资源管理、存储管理、连接与请求连续性、滚动维护、故障检测以及更自动化的部署方式。这也是成熟基础设施常见的演进路径。核心架构未必每隔几年推倒重来真正影响生产体验的往往是故障能否更快发现维护能否在线完成客户端能否正确切换以及运维动作能否被可靠地自动化。Exadata 抬高了 RAC 的性能上限RAC 与 Exadata 结合后讨论重点不再只是“多台服务器访问共享存储”。计算节点、存储节点、数据库软件和互联网络开始按一个完整系统协同设计。Oracle 在此次文章中提到Exadata 的 RDMA 互联操作可以在 14 微秒内完成。这个数字来自 Oracle 自己的产品资料具体效果仍会受到硬件代际、配置和工作负载影响但方向很明确当实例间通信和存储访问延迟下降后RAC 可以承载更重的 OLTP、分析、报表、批处理和混合负载。对 DBA 来说Exadata 并没有让 RAC 的诊断对象消失。Global Cache、服务分布、实例亲和性、热点块、节点间流量仍然需要看。变化在于数据库与基础设施的边界更紧了。很多性能和可用性能力已经不是某一个参数带来的而是整个平台共同提供的。多云不是把一个 RAC 集群随意拉跨三朵云Oracle 现在提供的部署范围已经远超传统机房本地 Exadata、OCI、Exadata CloudCustomer以及部署在 Azure、Google Cloud 和 AWS 数据中心内的 Oracle Database 服务。这里容易产生一个误解。所谓 RAC 进入多云并不是建议把同一个集群的节点随意分散到几家公有云再跨公网运行私有互联。Oracle 当前强调的是把托管的 Exadata 和 Oracle Database 服务放到超大规模云环境中让数据库更接近原有应用、数据和云原生服务。这改变的是部署位置和责任边界不是网络延迟规律。RAC 仍然依赖低延迟、稳定的实例互联和一致的共享数据访问。选择多云方案时确认“支持 RAC”只是第一步。应用到数据库的延迟、故障域设计、备份与容灾、监控入口、维护权限、数据驻留和费用模型同样需要逐项核对。过去 DBA 常问“这套 RAC 放在哪个机房”现在的问题可能变成“数据库应该靠近哪一组应用哪些操作由云服务接管哪些风险仍然归我们负责”AI 工作负载增加了新的压力但没有改写 RAC 的职责Oracle 把 RAC 的下一阶段与 Agentic AI 联系在一起。这个判断有现实基础AI Agent 如果持续访问企业数据会带来更多并发请求、更复杂的读写组合也会要求数据服务保持稳定。Vector Search 与传统交易、JSON、图、分析和批处理同时存在时数据库面对的负载边界确实会变得模糊。但不能由此推导出“上了 RACAI 系统就可靠”。RAC 保护的是数据库服务层的可用性和扩展能力。模型回答是否正确、RAG 检索是否命中、工具调用是否越权、Agent 是否形成错误循环属于另一组问题。更准确的说法是当 AI 应用开始依赖核心业务数据数据库层不能成为最脆弱的一环。RAC 可以继续承担它擅长的部分让多个实例共同服务并在节点故障和维护期间尽量维持数据库访问。AI 应用自己的质量与安全仍需单独设计。站在 DBA 的位置接下来该看什么25 年后的 RAC 比早期更自动化也能部署到更多环境但 DBA 的判断没有因此变轻。至少有五件事值得重新检查。按业务重要性梳理数据库服务而不是让连接随机散落在所有实例上。检查连接池、驱动、FAN 和 Application Continuity 配置并用真实故障演练验证结果。持续观察私有互联、Global Cache 等待、热点对象和实例间工作负载分布。把滚动补丁、节点维护、实例故障和存储故障分开测试记录应用实际感知到的中断。评估云或多云方案时先画清应用、数据库、网络、备份、容灾和管理面的责任边界。RAC 的价值不在于让 DBA 相信系统永远不会停而在于给系统留下处理故障和扩展容量的余地。这个判断在 2001 年成立到了多云和 AI 时代仍然成立。本文小结RAC 25 年的变化可以概括为三点核心的多实例共享数据库模型没有改变Exadata、Application Continuity 和自动化运维不断补齐外围能力云与多云扩大了部署范围也重新划分了运维责任。对 DBA 来说产品入口越来越像服务底层问题却没有消失。服务如何分布、故障如何被感知、请求如何恢复、数据放在哪里、责任由谁承担这些问题仍需有人做出判断。参考资料25 Years of Oracle RAC: From Mission-Critical Availability to Multicloud ScaleOracle Application ContinuityOracle Real Application Clusters 11g Release 2 White Paper