下课仔：xingkeit.top/7214/

在数据库领域，Oracle 一直扮演着“最后一道防线”的角色。核心交易系统、关键业务库、金融级应用，往往都跑在 Oracle 上。这种“核心中的核心”地位，决定了它对可用性的要求极为苛刻——停机一分钟，可能就是几十上百万的损失。

很多运维人员在接触 Oracle 高可用时，容易被各种术语绕晕：RAC、Data Guard、ASM、Failover、Switchover……这些概念单独拎出来都能理解，但放在一起怎么搭？遇到故障怎么切？日常怎么维护？

这篇实战指南，从最核心的架构入手，一步步拆解 Oracle 主机平台高可用的落地要点。

一、高可用的三层架构

Oracle 的高可用方案，可以抽象为三个层次：

第一层：实例级高可用 —— RAC

RAC（Real Application Clusters）的核心思想是“多个实例，一个数据库”。多台服务器运行多个 Oracle 实例，同时访问同一份数据库文件。任何一个实例宕机，业务请求自动切换到其他实例，应用层几乎无感知。

RAC 解决的是“实例故障”问题——服务器宕机、实例崩溃、网络抖动，都不影响数据库服务的连续性。

第二层：存储级高可用 —— ASM

ASM（Automatic Storage Management）是 Oracle 自家的存储管理方案。它把多块磁盘做成磁盘组，数据自动条带化、镜像化。一块磁盘坏了，ASM 自动从镜像读取数据，并重建到可用磁盘上。

ASM 解决的是“存储故障”问题——磁盘损坏、存储控制器故障，数据不丢、服务不停。

第三层：灾难级高可用 —— Data Guard

RAC 和 ASM 防范的是机房内部的故障，但如果整个机房断电、网络中断、或者发生自然灾害，就需要 Data Guard 出场。

Data Guard 通过日志同步，在主库和备库之间维持数据一致性。主库出问题时，可以手动或自动切换到备库，实现跨机房的灾难恢复。

这三层叠加在一起，构成了 Oracle 主机平台的高可用体系：RAC 扛实例故障，ASM 扛存储故障，Data Guard 扛机房级灾难。

二、RAC 实战要点

搭建 RAC 环境，有几个关键点容易踩坑。

共享存储是基础

RAC 的核心是“多个实例共享一份数据”。这意味着所有节点必须能访问同一份存储——通常是 SAN 存储或者 NAS。存储的 IO 性能和稳定性，直接决定 RAC 的整体表现。

私有网络要可靠

RAC 节点之间通过私有网络进行心跳检测和缓存融合（Cache Fusion）。这个网络如果出问题，节点可能会误判对方“死了”，导致节点驱逐（Node Eviction）。建议用万兆网卡、独立的交换机、做网络冗余。

CRS 是大脑

RAC 之上运行着 Cluster Ready Services（CRS），负责管理节点、资源、服务的状态。CRS 的健康状况，决定了集群能不能正常运转。日常巡检要重点关注 CRS 日志，发现异常及时处理。

网卡绑定不能省

无论是心跳网还是业务网，都要做网卡绑定（Bonding）。一块网卡坏了，另一块自动接管，避免单点故障。

三、ASM 实战要点

ASM 的配置相对简单，但有一些设计原则需要遵守。

外部冗余还是 ASM 冗余？

ASM 支持三种冗余模式：外部冗余（依赖存储自身的 RAID）、标准冗余（ASM 自己做镜像）、高冗余（三副本）。如果你的存储硬件已经做了 RAID，选外部冗余即可，避免双重冗余浪费空间。如果存储不可靠，用 ASM 冗余更安全。

故障组要分散

创建磁盘组时，可以把磁盘划分到不同的故障组（Failure Group）。ASM 会在不同故障组之间做镜像，确保一个故障组整体失效时，数据仍然可用。

监控磁盘状态

定期检查 ASM 磁盘的健康状态：

SELECT name, state, mode_status FROM v$asm_disk;

发现 OFFLINE 或 ERROR 的磁盘，要及时处理，避免磁盘组降级。

四、Data Guard 实战要点

Data Guard 的搭建相对复杂，但掌握几个核心概念之后，逻辑就清晰了。

同步模式怎么选？

Data Guard 支持三种数据保护模式：

• 最大性能：主库提交后立即返回，日志异步传输到备库。性能最好，但备库可能有数据延迟。

• 最大可用：正常情况下同步传输，备库确认才返回；备库故障时自动降级为异步。兼顾性能和安全性。

• 最大保护：必须备库确认才提交，性能影响大，且备库故障时主库也会宕掉。一般业务很少用。

大多数生产环境，选“最大可用”模式最平衡。

Switchover 和 Failover 的区别

• Switchover：计划内的切换，主备互换角色，应用无损。常用于机房维护、升级演练。

• Failover：计划外的切换，主库故障时备库强制接管。可能有少量数据丢失（取决于同步模式）。

日常运维要把 Switchover 演练常态化——真出故障时手忙脚乱，往往是因为从来没练过。

备库也能干活

很多人以为备库只能闲着等切换，其实 Oracle 的 Active Data Guard 允许备库以只读方式打开，可以用来跑报表、做查询、分担主库压力。

五、日常运维与监控

架构搭好只是第一步，真正的考验在日常。

巡检清单

• CRS 状态：crsctl check cluster

• ASM 磁盘组：asmcmd lsdg

• RAC 节点：srvctl status database -d orcl

• Data Guard 延迟：select name, value from v$dataguard_stats;

日志是朋友

• RAC 日志：$GRID_HOME/log//alert.log

• ASM 日志：$GRID_HOME/log//alert_asm.log

• Data Guard 日志：$ORACLE_BASE/diag/rdbms//trace/alert.log

遇到问题，第一时间翻日志，别瞎猜。

演练不能停

每季度做一次 Switchover 演练，每半年做一次 Failover 演练。真出故障时，肌肉记忆比大脑反应快。

六、总结：从“能用”到“高可用”

很多团队搭 RAC，只是照着文档敲完命令，能跑起来就算完事。但真正的“高可用”，不是安装完成的那一刻，而是在每一次故障、每一次切换、每一次演练中验证出来的。

RAC + ASM + Data Guard 这套组合拳，打好了，能扛住服务器宕机、能扛住磁盘损坏、能扛住机房断电。但前提是：架构设计合理、配置参数正确、日常监控到位、故障演练熟练。

花时间把这些做实，换来的是核心业务“稳如磐石”的底气。这笔投入，值。