1. 课程导入与RAC工程全景
在核心业务系统中，数据库停机往往意味着交易中断、订单丢失和品牌受损。单台数据库服务器无论配置多高，都绕不开两个硬约束：一是硬件故障必然发生，二是单机纵向扩展存在物理上限。Oracle RAC（Real Application Clusters，实时应用集群）正是为破解这两个约束而生的高可用数据库集群方案。本课程的目标，是带你从"知道RAC是什么"走到"能独立规划、部署、运维并排障一套RAC集群"。
高可用数据库集群的核心目标
高可用（High Availability，HA）不是"永不停机"，而是把不可用时间压缩到业务可接受的范围。工程上通常用两个指标衡量：RTO（Recovery Time Objective，恢复时间目标）和RPO（Recovery Point Objective，恢复点目标）。RTO回答"多久能恢复服务"，RPO回答"最多丢多少数据"。例如某支付系统要求RTO≤60秒、RPO=0，意味着故障切换必须在一分钟内完成，且不允许丢失已提交事务。
RAC通过三个机制逼近这一目标：
- 实例级冗余：多个实例同时打开同一个数据库，任一实例崩溃，其余实例继续提供服务，客户端通过TAF（Transparent Application Failover）或应用重连完成切换。
- 共享存储：所有实例访问同一份数据文件，数据只有一份，天然保证RPO=0（前提是存储本身冗余）。
- Cache Fusion：实例间通过私有网络直接传递数据块，避免磁盘争用，使多实例并发访问同一数据块成为可能。
需要明确：RAC解决的是实例级和节点级高可用，它不替代存储冗余（需ASM或RAID）、不替代站点级容灾（需Data Guard）、也不替代人为误操作的防护（需闪回或备份）。把RAC当成"万能高可用"是工程上最常见的认知偏差。
Oracle RAC体系结构总览
一套典型RAC集群由四层构成：客户端层（应用、连接池、SCAN监听）、集群节点层（多台数据库服务器，每台运行一个实例）、集群软件层（Grid Infrastructure，含Clusterware与ASM）、共享存储层（数据文件、控制文件、OCR、表决盘）。
其中几个关键组件必须理解清楚：
- Clusterware：负责节点成员管理、心跳检测、资源管理与故障切换，核心进程是CSSD（Cluster Synchronization Services Daemon），它通过私有网络心跳和表决盘（Voting Disk）判断节点存活。
- ASM：Automatic Storage Management，以磁盘组方式管理裸设备，提供条带化和镜像，是RAC共享存储的标准方案。
- OCR与表决盘：OCR（Oracle Cluster Registry）保存集群配置，表决盘用于解决脑裂（Split Brain）。两者都必须放在共享存储上，且建议多副本。
- SCAN：Single Client Access Name，客户端只连SCAN VIP，由集群自动分配到具体实例，屏蔽节点增减对应用的影响。
- 私有网络与公有网络：私有网络承载Cache Fusion和心跳，要求低延迟高带宽；公有网络承载客户端访问。两者必须物理隔离。
下图给出RAC集群的典型拓扑与数据/信号流向，帮助建立整体空间感：
工程实施生命周期
RAC工程不是"装完就结束"，而是一个覆盖规划、部署、验证、运维、优化的完整生命周期。每个阶段都有明确的交付物和判断标准：
| 阶段 | 关键任务 | 交付物 / 判断依据 |
|---|---|---|
| 需求与规划 | 确定RTO/RPO、节点数、存储容量、网络带宽 | 架构设计文档、IP规划表、存储规划表 |
| 环境准备 | OS安装、内核参数、用户与组、网络配置、共享存储映射 | 节点间SSH互信、时间同步、磁盘可见性检查通过 |
| Grid Infrastructure部署 | 安装GI、配置ASM磁盘组、创建OCR与表决盘 | crsctl stat res -t 全部资源 ONLINE |
| 数据库软件与建库 | 安装DB软件、用DBCA创建RAC数据库 | 所有实例可同时打开数据库，SCAN可连通 |
| 高可用验证 | 模拟实例崩溃、节点宕机、存储路径故障 | TAF切换成功、RTO达标、无数据丢失 |
| 运维与优化 | 备份恢复、补丁、性能调优、故障演练 | 定期演练报告、AWR对比、告警闭环 |
其中"环境准备"阶段最容易埋雷。例如私有网络若误用千兆网卡，Cache Fusion延迟会显著上升；时间不同步会导致OCR操作失败；共享存储未正确映射会让ASM无法发现磁盘。这些问题的代价在部署后期会成倍放大。
学习路径与工程视角
本课程后续章节将沿着上述生命周期展开：先讲架构与原理，再讲安装部署，然后进入日常运维、性能调优和故障处理。学习时建议始终带着三个问题：这个组件解决什么问题？它依赖什么？它失效时会发生什么？能把这三个问题回答清楚，才算真正掌握了RAC。
从工程视角看，RAC集群的每一个组件都对应一个明确的失效场景和恢复手段：CSSD对应节点心跳，ASM对应存储冗余，SCAN对应客户端接入，Cache Fusion对应实例间数据一致性。理解这张"组件—失效—恢复"的对应关系，是后续所有实操的基础。