Oracle 9i推出的RAC真正应用集群，是数据库高可用与可扩展架构的一次重要演进。它允许多台独立服务器通过专用高速网络互联，共同访问同一套存储上的数据库文件，对外表现为一个逻辑整体，任何节点失效都不会导致数据服务中断。
一、RAC的核心架构变化
在Oracle 9i之前，Oracle的并行服务器OPS架构虽然也能多节点访问，但依赖磁盘心跳和大量磁盘写操作来协调数据块锁，性能瓶颈明显。RAC重构了这一现象，引入了缓存融合（Cache Fusion）概念，节点间通过内存直接传输数据块映像，避免了绝大多数磁盘争用。
真正应用集群的名称强调其面向实际生产应用，而非实验室并行计算。它包含全局资源目录（GRD）、全局缓存服务（GCS）和全局队列服务（GES），这些后台进程分布在各节点，协同管理数据块状态和锁信息，使集群具备线性扩展潜力。
1. 全局资源目录的分散存储
GRD记录了集群中每个数据块当前所在的节点及锁模式，它并非集中在某一台机器，而是分散在所有节点内存中。这种无主设计消除了单点协调者，提升了整体健壮性。
当新节点加入集群，GRD信息会重新分布；某节点离开，其负责的资源条目由剩余节点接管。管理员无需手动干预，系统自动完成再平衡，这是RAC易管理性的基础。
二、缓存融合带来的性能突破
传统共享存储集群中，如果节点A修改了数据块，节点B要读取就必须先从磁盘读入或等待写盘，开销巨大。RAC的缓存融合让节点B直接通过互联网络从节点A内存复制最新块，延迟降到微秒级。
这一机制依赖高速专用网络，通常建议使用千兆以太网或InfiniBand。若互联带宽不足，缓存融合反而会成为瓶颈。因此部署RAC时，互联链路的质量往往比服务器单机性能更关键。
2. 实际场景中的读扩展
例如报表系统原本在单实例上跑影响交易，迁移到RAC后，可将重查询指向第二个节点，交易留在第一个节点。由于缓存融合保障数据一致性，报表看到的也是近实时业务数据，不必担心脏读。
这种读写分离不需应用改造，只需在连接串里配置负载策略，体现了真正应用集群对业务透明的好处，也是它区别于外包分库方案的最大优势。
三、高可用与故障切换能力
RAC通过VIP和CRS（集群就绪服务）实现连接级容错。某节点宕机，其虚拟IP被集群秒级漂移到存活节点，客户端连接虽短暂中断但重连即达可用实例，应用层通常只感知一次重试。
对比主机双机热备需长时间拉起备用库，RAC所有节点本就并行服务，故障转移几乎没有恢复时间。对于电信计费、银行清算等不允许停机的系统，该特性价值极高。
| 特性 | Oracle 8i OPS | Oracle 9i RAC |
|---|---|---|
| 数据块传递 | 经磁盘协调 | 内存直传 |
| 扩展方式 | 受限且复杂 | 在线加节点 |
| 故障影响 | 明显停顿 | 近无感知 |
四、管理与运维要点
使用RAC需配套集群软件管理存储与网络。Oracle 9i提供基础CRS，后续版本增强为Grid Infrastructure。日常监控应覆盖互联流量、全局锁等待和节点心跳延迟，这些指标异常早于业务报错。
备份策略与单实例一致，因共享存储只需在一个节点发起即可。但打补丁要注意滚动方式，先停一个节点更新再切流量，保证集群整体不中断，这也是真正应用集群运维的常规动作。
综合来看，Oracle 9i的RAC真正应用集群以缓存融合和分布式协调为核心，把高可用与扩展从附加方案变为内置能力，为后续网格计算打下根基。