一台服务器突然宕机，全院系统会停吗？看懂 Oracle RAC 的底层机制

凌晨两点，HIS 数据库的一台服务器突然故障。门诊挂号、住院医嘱、护士站、医保结算，会不会一起停摆？如果医院部署的是设计和维护得当的 Oracle RAC，另一台节点可以继续对外提供数据库服务。但这句话背后，远不只是“装了两台服务器”那么简单。

这篇文章不背官方定义。我们站在医院信息科程序猿的视角，把 RAC 的机制、故障切换以及应用连接讲明白。

01 / 先建立直觉

RAC 到底是什么？

RAC 是 Real Application Clusters 的缩写。它允许多台服务器上的多个 Oracle 实例，同时访问同一套数据库文件。

实例 InstanceSGA 内存 + 后台进程，是正在工作的“数据库发动机”。数据库 Database数据文件、控制文件、联机日志等，是被管理的“数据本体”。

RAC 不是两套数据库做同步，而是多个实例共同管理一套数据库。

HIS / EMR / 医保↓SCAN / Service

↙　　　　　　　　　↘

节点1：HIS1 实例节点2：HIS2 实例

共同访问：ASM 共享存储中的同一数据库

比如两节点集群中，服务器一运行实例 HIS1，服务器二运行实例 HIS2。二者看到的是同一批患者、同一张处方、同一条医嘱。

02 / 四个关键角色

是谁让集群真正跑起来？

① Clusterware：集群的“总调度”Oracle Clusterware 监控节点和资源，负责数据库实例、监听、VIP、服务的启动、停止与故障恢复。它还通过心跳判断节点是否存活。

当节点失联时，为防止两边同时写共享数据造成“脑裂”，集群会隔离或驱逐异常节点。

查看 RAC 集群资源复制

crsctl check cluster -all
crsctl stat res -t
olsnodes -n -s

② ASM：共享存储的“管家”ASM（Automatic Storage Management）统一管理共享磁盘。常见磁盘组包括：+DATA 存数据文件，+FRA 存归档、闪回与备份。

查看 ASM 磁盘组容量复制

SELECT name,
       state,
       type,
       total_mb,
       free_mb,
       ROUND(free_mb / total_mb * 100, 2) AS free_rate
  FROM v$asm_diskgroup;

③ SCAN、VIP、Listener：连接入口

名称	作用
Public IP	节点日常网络通信
Private IP	集群心跳及实例间数据块传输
VIP	节点故障后让客户端快速收到连接失败并重连
SCAN	为整个集群提供相对稳定的统一入口
Service	把具体业务组织并调度到合适的实例

医院应用不宜把连接固定到某台服务器的 SID，而应通过 SCAN 和业务服务名接入。

JDBC 连接示例复制

jdbc:oracle:thin:@//rac-scan.example.local:1521/his_service

④ Cache Fusion：RAC 的核心能力两个实例可能同时访问同一个 Oracle 数据块。Cache Fusion 通过私有网络，在实例内存之间传递数据块，并借助全局缓存和全局锁机制保证一致性。

HIS1 修改了某个患者费用数据所在的数据块。

HIS2 恰好也需要读取或修改这个数据块。

集群通过私网协调数据块版本和访问权限。

所需数据块可直接从 HIS1 的缓存传到 HIS2，不必每次先落盘再读取。

因此，RAC 私网质量非常重要。gc current request、gc cr request、gc block busy 等等待明显升高时，应关注私网延迟、热点表、热点索引块和跨实例访问。

03 / 故障现场

一台节点宕机后发生了什么？

Clusterware 通过心跳发现节点 1 异常。

异常节点被隔离，避免继续访问共享存储。

存活实例执行必要的实例恢复，处理未完成事务。

数据库服务在可用实例上继续运行，新连接转向存活节点。

应用连接池识别失效连接并重新建立连接。

容易被忽略的一点：RAC 提高的是数据库服务可用性，并不代表正在执行的业务请求绝对无感。节点故障时，原连接上的事务仍可能报错或回滚，应用必须具备超时、重连、事务重试和幂等控制。

对收费、退费、医保结算等业务，尤其不能“见异常就无脑重试”。必须先查询原交易状态，再决定是否重发，否则可能形成重复结算或单边账。

04 / 医院落地

程序猿真正应该关心什么？

按业务配置 Service。 可以把核心交易、报表分析、批量上传划分为不同服务，设置首选实例和可用实例，减少批处理对在线业务的冲击。

连接池要会感知故障。 设置合理的连接超时、校验和失效连接清理；关键接口补充可控重试与幂等校验。

排障时使用 GV$ 视图。 单实例常看 V$SESSION，RAC 要看 GV$SESSION，并始终记录 INST_ID。

压测不能只看总 TPS。 还要观察业务连接在实例间的分布、全局缓存等待、私网流量、热点块及存储延迟。

查看各实例状态复制

SELECT inst_id,
       instance_name,
       host_name,
       status,
       database_status,
       startup_time
  FROM gv$instance
 ORDER BY inst_id;

查看会话在各实例的分布复制

SELECT inst_id,
       service_name,
       status,
       COUNT(*) AS session_count
  FROM gv$session
 WHERE type = 'USER'
 GROUP BY inst_id, service_name, status
 ORDER BY service_name, inst_id, status;

排查跨实例阻塞复制

SELECT inst_id,
       sid,
       serial#,
       username,
       event,
       blocking_instance,
       blocking_session,
       sql_id
  FROM gv$session
 WHERE blocking_session IS NOT NULL;

终止指定实例上的会话复制

ALTER SYSTEM KILL SESSION 'sid,serial#,@inst_id' IMMEDIATE;

05 / 别误会

RAC 不等于备份，也不等于容灾

风险场景	RAC 能否解决
单个服务器或实例故障	主要解决目标
误删患者数据、错误更新	不能
共享存储整体损坏	不能单独解决
机房断电、火灾、网络中断	不能单独解决
恢复到某个历史时间点	需要备份与恢复体系