Oracle RAC（Real Application Clusters）并不是简单地把多个实例连到同一个数据库就能运行，它的启动依赖一套严密的层级化集群件体系。如果打乱底层集群件的加载次序，直接去启动数据库实例，往往会出现资源注册信息读不到、VIP无法上线、甚至节点被其他成员驱逐的情况。真正可靠的启动过程，应当从硬件和存储就绪开始，逐步交由Grid Infrastructure（GI）的各层组件接管，最后才在集群管理框架下打开数据库。
一、RAC启动前的物理与存储准备
在任何一个节点上电之前，必须确认共享存储已经正确映射且所有RAC节点都能看到相同的磁盘设备。RAC依赖ASM或者集群文件系统来存放OCR（Oracle Cluster Registry）和表决磁盘（Voting Disk），这两类文件在启动初期就被集群同步服务频繁读写。如果存储链路在启动时抖动，CSS（Cluster Synchronization Services）可能无法形成法定人数，从而让节点在启动中途被踢出集群。
除了存储，还需要检查各节点的心跳网络与公网。心跳网络用于节点间通信，公网用于客户端访问和VIP漂移。很多运维人员在机房断电恢复后急于开机，却忽略了交换机迟迟未转发组播包，结果OHASD起来后一直卡在探测阶段。建议先用操作系统工具确认多路径软件（如multipath或ASMlib）已将磁盘标记为可用，并且各网卡状态为UP，再继续往上启动集群件。
另外，操作系统层的用户和环境变量也必须就绪。Grid Infrastructure通常安装在独立的grid用户下，ORACLE_HOME、ORACLE_BASE以及PATH需要正确指向GI的bin目录。若用root调用crsctl却没加载对应环境变量，可能不会报错但实际操作的是错误版本的二进制文件。因此启动前用id确认当前用户，并用which crsctl确认命令路径，是避免低级故障的好习惯。
二、Grid Infrastructure集群件的逐级启动
RAC的集群件启动是分层的，最底层是OHASD（Oracle High Availability Services Daemon），它由操作系统init或systemd在开机时拉起。OHASD负责启动Ohasd对应的资源，包括CSSD、CRSD等守护进程。在Linux平台上，可以通过crsctl check ohad或者查看systemd单元ohas.service来确认它是否存活。只有OHASD正常，上层组件才有被调度的可能。
接着，CSSD（Cluster Synchronization Services Daemon）会读取表决磁盘并尝试与集群中其他节点的CSSD通信，形成集群成员关系。这一步决定了哪些节点能留下来。如果只有一个节点先开机，而其他节点还没通电，单节点也能基于本地表决盘先启动，但一旦后续节点加入，会重新协商。随后CRSD（Cluster Ready Services Daemon）启动，它根据OCR里的资源配置信息，把VIP、监听、ASM、数据库等逐步拉起。可以用以下命令观察集群状态：
# 以root或grid用户执行 crsctl check cluster -all crsctl status resource -t
在实际排错中，最常见的问题是CRSD起不来，原因多为OCR所在磁盘权限错误，或者前一次关机时OCR写入被中断。此时集群虽然OHASD在跑，但没有任何资源被管理。遇到这种情况不要手动用sqlplus去启库，而应先修复OCR访问，或借助crsctl start crs重新拉起整个GI栈。GI的启动顺序本质是由依赖关系树决定的，跳跃式操作会破坏资源代理的状态机。
三、使用crsctl与srvctl完成数据库启动
当crsctl status resource -t显示CRS、CSS、ASM以及VIP均为ONLINE后，才可以交给srvctl去管理数据库实例。srvctl是面向资源语义的工具，它会通过CRSD下发启动请求，而不是像sqlplus那样直接连实例。标准做法是先确认数据库资源已注册，再启动整个数据库或单个实例：
# 查看数据库资源名 srvctl config database # 启动整个RAC数据库（所有实例） srvctl start database -db orcl # 仅启动某节点实例 srvctl start instance -db orcl -node rac01
有些场景下，运维人员喜欢直接登录到节点用sqlplus / as sysdba然后startup，这在单机或非托管环境没问题，但在RAC托管环境下会让CRSD记录的实例状态与实际不符。后续CRS做故障转移时可能误判，导致VIP不漂移或实例被重复拉起。因此，只要集群件在线，就应该用srvctl作为统一入口。
如果集群整体刚从断电恢复，推荐在所有节点OS启动后，在一个节点以root执行crsctl start crs，其他节点同样操作，等全部节点CRS栈就绪，再用srvctl启动数据库。这种顺序保证了OCR和表决盘在一致状态下被所有节点访问，也符合Oracle官方支持的启动路径。对于紧急维护后的重启，还可以用crsctl start cluster -all一次性拉起所有节点的集群件，再启库，减少人工逐台操作的失误。
四、常见启动异常与排查思路
启动过程中最容易碰到的是节点被驱逐（Node Eviction）。这通常发生在CSSD未能在超时时间内完成投票，原因包括心跳网络延迟、存储IOHang、或是服务器负载过高导致CSSD进程未被调度。排查时应首先看/u01/app/grid/diag/crs/下的日志，尤其是ocssd.log，确认被踢前的最后通信状态。同时用操作系统命令检查当时CPU steal值和磁盘await，排除资源挤占。
另一个常见问题是ASM磁盘组没挂载，数据库资源卡在INTERMEDIATE。ASM由GI管理，若磁盘组因权限或字符串设备变更而缺失，CRSD不会把数据库标记为可启动。此时应先用srvctl start diskgroup -g DATA手动拉起磁盘组，确认所有数据文件和OCR盘可见，再回头启动数据库。切忌在ASM未就绪时改参数强行启库，否则控制文件找不到就会直接abort。
最后是开机自启策略的配置。通过crsctl enable crs可以让GI随OS启动，但有些环境为防脑裂会临时禁用，维护后忘记开启，下次宕机恢复就变成纯手工拉起，容易出错。建议每次维护完用crsctl config crs确认状态为enable，并把启动顺序写成运维手册，明确先存储、再网络、后GI、最后srvctl启库，才能保障RAC在长期运行中稳定重启。
Oracle_RAC集群启动CRS修改时间：2026-08-17 03:30:16