深入了解 Oracle RAC 架构与特性

在当今高度依赖数据驱动业务的环境中，数据库系统的可用性、可伸缩性和性能至关重要。单实例数据库虽然功能强大，但在面对硬件故障、 planned downtime（计划内停机）以及不断增长的工作负载时，往往存在单点故障（Single Point of Failure – SPOF）和扩展性瓶颈。为了解决这些挑战，Oracle 推出了其旗舰级高可用性和可伸缩性解决方案——Oracle Real Application Clusters (RAC)。

Oracle RAC 允许多个 Oracle 数据库实例在不同的服务器上同时访问同一个物理数据库文件。通过将计算资源分布在多个节点上，RAC 不仅消除了传统单实例数据库的单点故障，还提供了近乎线性的可伸缩性，能够应对极端的工作负载高峰，并支持计划内的维护操作（如滚动升级）而无需完全停机。

本文将深入探讨 Oracle RAC 的核心架构、关键组件、工作原理、主要特性、以及部署和管理的考量，旨在为读者提供一个全面而深入的理解。

第一部分：Oracle RAC 的基本概念与需求背景

1. 单实例数据库的局限性

在深入 RAC 之前，理解单实例数据库的局限性是必要的：

单点故障 (SPOF)： 如果运行数据库实例的服务器硬件（CPU、内存、主板、网卡等）或操作系统发生故障，整个数据库将无法访问，导致业务中断。
计划内停机 (Planned Downtime)： 进行硬件维护、操作系统补丁、数据库软件升级时，通常需要停掉数据库实例，造成业务停机时间。
垂直伸缩的限制： 虽然可以通过升级服务器的硬件（CPU、内存）来提高性能（垂直伸缩），但这有物理极限，且成本随着性能提升呈非线性增长。
资源瓶颈： 即使是强大的单服务器，其 I/O 子系统、网络带宽或 CPU 核心数最终也会达到瓶颈，限制了数据库处理高并发请求的能力。

2. RAC 的基本理念

Oracle RAC 的核心理念是“Shared-Disk Cluster”（共享磁盘集群）。这意味着集群中的所有节点（服务器）共同访问存储在同一个共享存储系统上的数据库文件（数据文件、控制文件、重做日志文件等）。每个节点上运行一个独立的 Oracle 数据库实例，拥有自己的 SGA (System Global Area) 和后台进程。这些实例通过高速的集群互连网络（Interconnect）相互通信，协同工作，共同管理和访问共享的数据。

当客户端连接到 RAC 数据库时，它可以被路由到集群中的任何一个可用的实例。如果某个实例或其所在的节点发生故障，客户端连接可以快速地切换到集群中的其他健康实例上，从而实现了高可用性。同时，随着工作负载的增长，可以通过向集群中添加更多节点（服务器）来提高整体处理能力，实现水平伸缩（Horizontal Scaling）。

第二部分：Oracle RAC 的核心架构与关键组件

Oracle RAC 的架构是一个复杂但精密的协同系统，其主要构成部分包括：

1. 集群硬件 (Cluster Hardware)

多个服务器节点 (Nodes)： 这是 RAC 的基础，每台服务器运行一个 Oracle 实例。这些服务器通过高速网络连接在一起。
共享存储系统 (Shared Storage)： 所有节点都能访问的存储系统，用于存放数据库文件、控制文件、重做日志文件、归档日志文件、参数文件、密码文件、投票磁盘 (Voting Disk) 和 OCR (Oracle Cluster Registry)。共享存储通常通过光纤通道 SAN (Storage Area Network)、iSCSI SAN 或高性能的 NAS (Network Attached Storage) 实现。
高速集群互连网络 (High-Speed Interconnect)： 这是 RAC 最关键的网络组件，用于集群节点间的私有通信，特别是用于 Cache Fusion 数据的块传输和集群控制信息的交换。要求极高的带宽和极低的延迟。通常使用 InfiniBand 或高性能 Ethernet (如 10 Gigabit Ethernet 或更高速率)。
公共网络 (Public Network)： 客户端连接数据库实例的网络接口。
冗余组件： 为了提高可用性，集群中的网络、存储路径、电源等关键组件通常都会配置冗余。

2. Oracle 集群件 (Oracle Clusterware) / Grid Infrastructure

Oracle Clusterware 是 Oracle 提供的一个独立的集群管理软件，它是 RAC 的基石。从 Oracle 11g R2 开始，Clusterware 与 Oracle 的 ASM (Automatic Storage Management) 被打包在一起，统称为 Grid Infrastructure。

Grid Infrastructure 的主要功能包括：

集群节点管理： 监控集群中所有节点的健康状况。
资源管理： 管理和监控集群中的各种资源，包括数据库实例、监听器、服务、IP 地址、存储卷等。
高可用性框架 (High Availability Framework)： 当某个资源（如实例）失败时，Clusterware 能够自动重启它或将其转移到其他健康节点上。
投票磁盘 (Voting Disk)： 存储集群节点成员信息。用于解决“脑裂”(Split-Brain) 问题，确保在网络分区时只有一个子集能继续运行，保持数据一致性。
Oracle 集群注册表 (Oracle Cluster Registry – OCR)： 存储集群和 RAC 资源的配置信息，如数据库名称、实例名、监听器配置、服务配置等。OCR 是集群的元数据仓库。

Clusterware 运行一系列重要的后台进程，例如 crsd (Cluster Ready Services Daemon)、cssd (Cluster Synchronization Services Daemon)、ocssd (Oracle Cluster Synchronization Services Daemon) 等，负责集群的成员管理、资源监控和故障切换。

3. Oracle 数据库实例 (Oracle Database Instances)

每个节点上运行一个独立的 Oracle 数据库实例。在 RAC 环境中，这些实例不是完全独立的，它们通过 Clusterware 和高速互连网络协同工作。每个实例有自己的：

SGA (System Global Area)： 包含数据库缓冲区缓存 (Database Buffer Cache)、共享池 (Shared Pool)、重做日志缓冲区 (Redo Log Buffer) 等内存结构。
后台进程： 包括 DBWn (Database Writer)、LGWR (Log Writer)、PMON (Process Monitor)、SMON (System Monitor) 等，以及一些 RAC 特有的后台进程。

RAC 特有的后台进程：

LMON (Lock Monitor)： 全局锁定服务监控器，管理全局锁资源和死锁检测。
LMSn (Lock Manager Server, n=0…*): 全局锁定服务服务器，负责在集群中的实例之间传输数据块（用于 Cache Fusion）。这是 Cache Fusion 的核心进程。
LMD (Lock Manager Daemon): 全局锁定服务守护进程，处理全局资源请求。
GCS (Global Cache Service)： 由 LMSn 进程实现，负责管理集群中的数据块缓存一致性。它跟踪每个数据块在哪个实例的缓存中，以及其状态（如独占、共享、无主）。
GES (Global Enqueue Service)： 由 LMON 和 LMD 进程实现，负责管理集群中的非块资源（如锁、latch）的一致性。

4. 共享数据库文件 (Shared Database Files)

集群中的所有实例共享同一套物理数据库文件，包括：

数据文件 (Datafiles)： 存储实际的应用数据。
控制文件 (Control Files)： 包含数据库的物理结构信息，如数据文件、重做日志文件的名称和位置，以及数据库状态等。
在线重做日志文件 (Online Redo Log Files)： 记录所有数据库更改，用于实例恢复。在 RAC 中，每个实例拥有自己的一组重做日志文件，但所有文件都存放在共享存储上，并且在需要时可以由其他实例访问进行恢复。
归档重做日志文件 (Archived Redo Log Files)： 在线重做日志文件的历史副本，用于介质恢复。
服务器参数文件 (SPFILE) 或 PFILE： 数据库的配置参数。SPFILE 推荐用于 RAC，因为它是一个共享文件，所有实例可以基于它启动，并且动态参数更改对所有实例可见（或应用到特定实例）。
密码文件 (Password File)： 允许用户以 SYSDBA 或 SYSOPER 身份通过网络连接到数据库并进行管理。

5. 客户端连接与服务 (Client Connectivity and Services)

客户端通过公共网络连接到 RAC 数据库。在现代 RAC 中，通常使用 SCAN (Single Client Access Name) Listener。

SCAN Listener： 一个或多个监听器运行在 Grid Infrastructure 管理的虚拟 IP 上。客户端只需配置连接字符串指向 SCAN Name，而无需指定具体的节点或实例 IP。SCAN Listener 能够感知集群中所有实例的状态和负载，并将客户端连接请求智能地路由到合适的实例上。这极大地简化了客户端配置，并提供了连接级的高可用性和负载均衡。
服务 (Services)： Oracle RAC 推荐使用服务来管理工作负载。服务是一组实例及其相关联的工作负载属性的抽象。可以将特定的应用程序连接到特定的服务，并通过服务控制哪些实例提供该服务，以及负载均衡和故障切换策略。这比直接连接到实例更加灵活和可管理。

第三部分：Cache Fusion 工作原理

Cache Fusion 是 Oracle RAC 的核心技术，也是其能够实现高性能共享磁盘架构的关键。它解决了多个实例同时访问和修改同一数据块时可能出现的缓存一致性问题。

挑战：缓存一致性

在一个共享磁盘系统中，如果多个实例都有同一个数据块的副本在自己的 Buffer Cache 中，并且其中一个实例修改了这个数据块，那么其他实例中的旧副本就变成了“脏块”或“stale block”，不再代表数据的最新状态。如果没有有效的机制来管理这些缓存副本，就会导致数据不一致甚至损坏。

Cache Fusion 的解决方案

Cache Fusion 通过高速互连网络，允许实例之间直接传输数据块，而不是将脏块写回磁盘再由其他实例从磁盘读取。这显著减少了磁盘 I/O，提高了性能。

工作流程示例：

假设数据块 X 最初在 Instance A 的 Buffer Cache 中，Instance B 需要修改数据块 X。

Instance B 在其 Buffer Cache 中查找数据块 X，发现没有（缓存未命中）。
Instance B 向集群的 Global Cache Service (GCS) 发送请求，询问数据块 X 的位置和状态。
GCS（由 LMSn 进程管理）通过全局资源目录 (GRD) 查找数据块 X 的信息，发现 Instance A 拥有数据块 X 的一个副本，并且可能已经修改了它（处于一个比磁盘上更“当前”的状态）。
GCS 通知 Instance A 将数据块 X 的当前副本（可能包括尚未写入磁盘的更改）通过高速互连网络直接发送给 Instance B。
Instance A 在发送数据块 X 之前，可能会在自己的缓存中将该块的状态标记为“降级”（例如，从独占 Exclusive Mode 降级为共享 Shared Mode，或者甚至释放所有权）。Instance A 还会向 Instance B 发送 redo 信息，以便 Instance B 可以应用这些更改。
Instance B 接收到数据块 X 及其相关的 redo 信息，将其加载到自己的 Buffer Cache 中，应用 redo 信息以使其成为最新状态，然后可以在本地修改该块。
同时，GCS 更新 GRD 中关于数据块 X 的所有权和状态信息。

通过这个过程，数据块在实例之间高效地流动，避免了不必要的磁盘写入和读取。GCS 和 GES 负责协调所有实例对共享资源的访问，维护数据块和非块资源的全局一致性。LMSn 进程则负责实际的数据块传输。

Cache Fusion 的效率高度依赖于 Interconnect 的性能。低延迟和高带宽的 Interconnect 是 RAC 性能的基石。

第四部分：Oracle RAC 的主要特性与优势

基于上述架构和 Cache Fusion 技术，Oracle RAC 提供了以下关键特性和优势：

高可用性 (High Availability – HA)：
- 实例故障切换： 如果集群中的某个实例崩溃，Clusterware 会自动检测到，并快速在另一个健康节点上恢复该实例相关的资源（如服务）。连接到该实例的客户端会收到连接错误，但如果应用程序使用透明应用故障切换 (Transparent Application Failover – TAF) 或更新的基于服务的应用连续性 (Application Continuity – AC) 特性，它们可以自动重连到其他健康的实例，对用户的影响最小化。
- 节点故障切换： 如果整个服务器节点发生故障，其上运行的实例及其关联资源会被 Clusterware 自动迁移或在其他节点上启动。
- 存储路径冗余： 配合多路径软件（如 Oracle ASMLib 的多路径支持或第三方多路径软件），即使部分存储路径故障，数据库访问也不会中断。
- 计划内维护： 可以在不停止整个数据库的情况下，对集群中的个别节点进行维护、打补丁、升级操作系统或 Oracle 软件（通过滚动升级）。
可伸缩性 (Scalability)：
- 水平伸缩： 随着工作负载的增加，可以通过向集群中添加更多节点来增加计算资源（CPU、内存）。每个新增节点都运行一个实例，加入到共享数据访问的处理能力中。
- 读/写工作负载： RAC 特别适合读写混合型工作负载，因为它允许多个实例同时处理对同一数据集的读写请求，Cache Fusion 高效地同步这些更改。
- 应用负载均衡： 通过 SCAN Listener 和服务，可以将客户端连接和工作负载分散到集群中的不同实例上，实现有效的负载均衡。
高性能 (High Performance)：
- Cache Fusion： 显著减少了磁盘 I/O，通过内存到内存的数据块传输提高了数据访问速度。
- 并行处理： 多个实例可以并行处理来自不同会话的请求。
- 优化共享资源访问： GCS/GES 精细地管理对数据块和其他资源的并发访问，最大化吞吐量。
管理性 (Manageability)：
- 统一管理工具： 提供一套工具来管理整个集群和数据库，如 srvctl (Server Control Utility) 用于管理数据库、实例、监听器、服务等资源，crsctl (Clusterware Control Utility) 用于管理 Clusterware 资源和状态，asmcmd (ASM Command-Line Utility) 用于管理 ASM 存储。
- 自动存储管理 (ASM)： 强烈推荐与 RAC 一起使用。ASM 提供了一个逻辑卷管理器，简化了数据库文件的管理，提供了自动的数据分布和冗余功能（如条带化和镜像）。
- 服务 (Services)： 简化了工作负载的管理、分配、负载均衡和故障切换策略的配置。
灵活性 (Flexibility)：
- 滚动升级 (Rolling Upgrades)： 可以在不中断数据库服务的情况下，逐个节点升级 Oracle 数据库软件版本、应用补丁集 (Patch Set) 或补丁 (Patch)。
- 动态资源管理： 可以动态地启动、停止实例或服务。

第五部分：Oracle RAC 的部署与管理考量

虽然 RAC 提供了强大的功能，但其部署和管理比单实例数据库更复杂，需要仔细规划和考虑：

硬件要求：
- 服务器： 所有节点最好使用相同配置的硬件和操作系统版本，以简化管理和避免兼容性问题。
- 共享存储： 必须具备高可用、高性能的共享存储系统，并配置多路径冗余。ASM 是首选的存储管理方式。
- 网络： Interconnect 网络必须是低延迟、高带宽的私有网络，并且有冗余路径。公共网络也应考虑冗余。网络规划是 RAC 成功的关键之一。
软件要求：
- 操作系统： 所有节点需要运行 Oracle 认证的相同版本的操作系统。
- Grid Infrastructure： 必须先安装和配置 Grid Infrastructure，然后才能安装 RAC 数据库软件。
- Oracle 数据库软件： 选择 RAC 版本的数据库软件。
应用兼容性：
- 连接池： 应用程序必须使用连接池，并且连接池需要支持透明应用故障切换 (TAF) 或应用连续性 (AC)，以便在实例故障时能够自动重连。
- 事务设计： 长时间运行的事务或持有大量锁的事务可能会影响 Cache Fusion 的效率。应尽量保持事务简短。
- 序列 (Sequence)： 默认情况下，RAC 中的序列是缓存的，这可能导致在实例故障或关闭时序列号不连续（但唯一性得到保证）。如果需要连续的序列号，可以调整序列的缓存设置或使用 NOORDER 选项。
- 全局临时表 (Global Temporary Tables)： 默认情况下，GTT 数据是会话私有的。在 RAC 中，如果会话故障转移到另一个实例，其 GTT 数据会丢失。需要特殊处理或设计规避。
监控与故障排除：
- 集群健康监控： 需要监控所有节点、Grid Infrastructure 资源、数据库实例、网络、存储等。Oracle Cluster Health Monitor (CHM) 是一个有用的工具。
- 等待事件： RAC 特有的等待事件（如 gc buffer busy, gc current block 2-way, gc cr block 3-way 等）对于诊断 Cache Fusion 性能问题至关重要。
- 统一日志： RAC 系统的诊断信息分散在多个节点上，需要有效的日志收集和分析方法。
备份与恢复 (Backup and Recovery)：
- RMAN (Recovery Manager)： 是 RAC 备份和恢复的首选工具。RMAN 可以并行地使用多个通道，连接到不同的实例进行备份，提高效率。所有实例共享归档日志，RMAN 可以从任何一个实例访问这些日志进行恢复。
许可证费用：
- Oracle RAC 需要额外的许可证费用，通常基于集群中所有节点的 CPU 核心数计算，成本相对较高。

第六部分：与其他高可用和可伸缩解决方案的比较

Oracle RAC 是 Oracle 解决方案组合中的一部分，用于提供 HA 和 Scalability。其他相关的技术包括：

Oracle Data Guard： 提供物理或逻辑备库，用于灾难恢复 (Disaster Recovery – DR) 和高可用性。Data Guard 通常提供异步或同步的数据复制，适用于远距离复制和整个数据库的故障切换。RAC 主要用于单数据中心的 HA 和 Scale-up/out，而 Data Guard 用于跨数据中心的 HA 和 DR。两者可以结合使用（RAC 主库 + Data Guard 备库）。
Oracle Sharding： 将大型数据库水平分割成多个独立的小型数据库（分片），每个分片可以部署在独立的服务器上。Sharding 主要用于解决超大规模数据集的伸缩性问题，每个分片是独立的数据库，没有共享存储和 Cache Fusion。适用于读写分离或按业务维度划分数据的场景。与 RAC 不同，Sharding 对应用透明性要求更高，通常需要特定的 Sharding Advisor 和管理工具。
Active-Passive Cluster： 在这种模式下，只有一个节点上的数据库实例是活动的，另一个节点处于待机状态。当主节点故障时，备用节点接管。这种模式相对简单，但资源利用率低（备用节点通常空闲），且故障切换时间可能比 RAC 长。RAC 是 Active-Active Cluster 的典型代表。

Oracle RAC 在需要同一个数据集的高可用性、高性能和可伸缩性的企业关键应用场景中具有独特的优势，尤其适合 OLTP（在线事务处理）工作负载。

总结

Oracle Real Application Clusters (RAC) 是 Oracle 数据库企业版提供的一项强大功能，通过允许多个实例共享同一份数据库存储，提供了卓越的高可用性、可伸缩性和性能。其核心在于 Oracle Clusterware (Grid Infrastructure) 管理集群资源，以及 Cache Fusion 技术实现高效的跨实例缓存数据块管理。

虽然 RAC 的部署和管理具有一定的复杂性，需要精心规划硬件、网络和存储，并考虑应用程序的兼容性，但对于需要消除单点故障、支持海量用户并发访问以及应对不断增长数据和工作负载的关键业务系统而言，RAC 是一个成熟且功能强大的解决方案。深入理解其架构和工作原理，特别是 Cache Fusion，是成功部署和维护 Oracle RAC 环境的关键。随着技术的演进，SCAN Listener、服务以及应用连续性等特性进一步提升了 RAC 的易用性和客户端故障切换能力，使其继续成为构建高可用、高性能企业级数据库的首选技术之一。