1. 高可用数据库系统建设导论

在开始讨论 Oracle Cloud 上的高可用数据库建设之前，需要先厘清一个常被混淆的概念：高可用性并不等于“数据库永不宕机”。任何系统都存在故障概率，高可用性的本质是把故障带来的业务中断控制在可接受范围内——通过冗余、快速检测、自动切换和数据保护，让系统在组件失效时仍能继续提供服务，或在最短时间内恢复服务。衡量它的核心指标是可用性等级，通常用“几个9”表示：99.9%（年停机约8.76小时）、99.95%（约4.38小时）、99.99%（约52.6分钟）、99.999%（约5.26分钟）。等级每提高一个9，架构复杂度和成本都会显著上升，因此工程上追求的是“与业务相匹配的可用性”，而非盲目堆叠冗余。

与可用性紧密相关但含义不同的是可靠性与可恢复性。可靠性关注系统在给定时间内不出故障的概率；可恢复性关注故障发生后恢复到可用状态的能力，其关键参数是 RTO（恢复时间目标）和 RPO（恢复点目标）。RTO 决定业务能容忍中断多久，RPO 决定业务能容忍丢失多少数据。这两个指标直接决定了后续架构选型：RPO 接近零通常需要同步复制或 Data Guard 最大保护/最高可用模式，而允许分钟级 RPO 则可采用异步复制以换取更低成本和更远距离的容灾能力。

Oracle Cloud 高可用体系概览

Oracle Cloud Infrastructure（OCI）的高可用能力是分层提供的，从底层基础设施到数据库内核形成一条完整的防护链。理解这条链路，是后续所有工程建设决策的基础。

在基础设施层，OCI 通过区域（Region）、可用性域（Availability Domain，AD）和故障域（Fault Domain，FD）三级隔离实现物理冗余。一个区域通常包含三个相互独立的可用性域，每个 AD 拥有独立的电力、冷却和网络；AD 内部又划分为多个故障域。把数据库的不同副本部署在不同 AD 或 FD，就能在单点硬件、单机架甚至单数据中心故障时保持服务。此外，OCI 的虚拟云网络（VCN）、负载均衡和块存储服务本身也具备跨 AD 的高可用设计。

在数据库层，Oracle 提供两条主要技术路线。其一是 Data Guard：通过主库与备库之间的重做日志传输实现数据同步或异步复制，支持最大保护、最高可用、最高性能三种保护模式，配合 Fast-Start Failover 可实现自动切换。其二是 Oracle RAC：多个实例共享同一份存储，通过 Cache Fusion 实现实例级冗余，单实例故障时其余实例继续服务，RTO 可低至秒级。在 OCI 上，二者可以组合使用，形成“实例冗余 + 站点冗余”的双重保护。

在托管服务层，Oracle 提供 Base Database Service 和 Autonomous Database。前者让用户在 VM 或裸金属上自主管理数据库，可灵活配置 Data Guard、RAC；后者由 Oracle 自动完成打补丁、备份、扩缩容和故障切换，内置 99.995% 的可用性目标。选择哪条路线，取决于团队对控制力和运维负担的权衡。

工程建设的核心目标与关键指标

把上述能力落地为可交付的工程，需要明确建设目标。一个高可用数据库系统工程通常围绕四个目标展开：业务连续性（故障时服务不中断或快速恢复）、数据零丢失或最小丢失（满足 RPO）、可验证的切换能力（切换不是纸面方案，而是经过演练的）、可观测与可运维（故障能被及时发现和定位）。这四个目标缺一不可，只做冗余不做演练，等于把风险留到真实故障时才暴露。

在指标层面，除了可用性等级、RTO、RPO，工程上还需要关注几个具体参数。以 Data Guard 为例，保护模式直接决定 RPO：最大保护模式要求主库事务提交前至少一个备库确认收到重做日志，RPO 为零但主库可能因备库不可用而挂起；最高可用模式在备库不可用时自动降级为主库继续运行，兼顾零丢失与可用性；最高性能模式异步传输，RPO 通常为秒级到分钟级。再如 Fast-Start Failover 的 FastStartFailoverThreshold 参数，默认 30 秒，决定观察者等待多久后触发自动切换，这个值需要与业务 RTO 匹配。RAC 侧则关注实例恢复时间、Cache Fusion 延迟和节点驱逐策略。

下面给出一个可用于工程启动阶段的指标定义示例表，帮助团队在建设前对齐目标。表中数值为教学示例，实际项目需根据业务等级重新评估。