在Oracle RAC（Real Application Clusters）架构中，CRS（Cluster Ready Services，集群就绪服务）是整个集群体系的基石。它位于操作系统之上、数据库实例之下，负责协调集群中各个节点的通信、资源调度和故障处理。可以说，没有CRS正常工作，RAC集群就无法提供高可用能力。理解CRS的工作机制，是每一位RAC DBA的必修课。
CRS的核心组件与后台进程
CRS并非一个单一的程序，而是一组相互协作的服务和进程的集合。从Oracle 11g R2开始，CRS与ASM、事件服务等整合成了GI（Grid Infrastructure），但CRS作为资源管理的核心地位没有变化。要理解CRS，首先要认识它的几个关键后台进程。
第一个是ohasd（Oracle High Availability Services Daemon），它是整个GI栈中最先启动的进程，由操作系统init或systemd直接拉起，被称作集群的init进程。ohasd负责启动并守护上层的一系列agent进程，如果ohasd本身异常，整个集群将无法启动。第二个是cssd（Cluster Synchronization Services Daemon），它通过心跳网络（private network）和投票磁盘（voting disk）来维护节点间的成员关系，判断节点是否存活，这是防止脑裂（split brain）的关键机制。第三个是crsd（Cluster Ready Services Daemon），它负责集群资源的启动、停止、监控和故障转移，我们平时看到的VIP、监听、数据库实例等资源都由crsd统一调度。最后是evmd（Event Manager Daemon），负责发布和传播集群事件，当资源状态发生变化时，evmd会及时通知其他组件做出响应。
这些进程之间存在明确的层级关系：ohasd在最底层，负责拉起cssd、crsd、evmd等守护进程；crsd下面又有rootagent和oraagent等agent进程，分别以root和oracle用户执行具体的资源动作。理解这个层级结构对排查启动故障非常有帮助，因为故障排查时需要自底向上逐层确认进程状态。
CRS如何管理集群资源实现高可用
CRS把集群中的一切都抽象为资源（resource），比如虚拟IP（VIP）、SCAN、监听器、ASM实例、数据库实例、服务等。每个资源都有一个类似ora.rac1.vip这样的注册名，CRS会持续监控这些资源的状态，一旦发现异常就按照预定义的策略采取行动。
以数据库实例为例，当某个节点发生宕机时，CRS的监控机制会在心跳超时后确认该节点故障，随后启动故障转移流程：该节点上的VIP会被漂移到幸存节点上，客户端连接到漂移后的VIP时会被快速拒绝并重连到其他节点，这就是所谓的VIP快速故障切换，它让客户端不必长时间等待TCP超时。同时，故障节点上的数据库实例被标记为offline，如果配置了service级别的failover，服务会自动在其他存活节点上重新拉起，客户端通过SCAN和service配置实现透明重连。
查看资源状态最常用的命令是crsctl stat res -t，它以树形结构展示所有资源的名称、类型和目标状态、实际状态：
-- 查看集群所有资源状态 crsctl stat res -t -- 单独查看数据库资源详情 crsctl stat res ora.orcl.db -v -- 查看集群节点状态 olsnodes -n -s
值得注意的是，CRS监控资源采用的是目标状态模型，即每个资源有TARGET和STATE两个属性。当TARGET为ONLINE而STATE为OFFLINE时，说明资源本应在线但实际离线，CRS会尝试自动重启该资源；如果重启超过阈值（默认由restart_attempts等属性控制）仍然失败，资源会被置为UNKNOWN或FAILED状态，需要DBA介入。这种机制保证了大部分瞬时故障能够被自动修复，无需人工干预。
CRS的日常管理与启动故障排查
日常运维中，CRS的管理主要通过crsctl和srvctl两个工具完成。两者的分工需要区分清楚：crsctl偏向底层，用于管理整个CRS栈、ohasd以及资源监控；srvctl偏向应用层，用于管理数据库、实例、服务、监听等具体对象。一般建议管理数据库资源时优先使用srvctl，因为srvctl会同步更新OCR（Oracle Cluster Registry）中的注册信息，而直接用crsctl stop等底层命令操作应用资源可能造成注册信息与实际状态不一致。
-- 停止整个集群栈（root用户执行） crsctl stop crs -- 启动整个集群栈 crsctl start crs -- 禁止集群开机自启 crsctl disable crs -- 使用srvctl启动数据库及其实例 srvctl start database -d orcl -- 启动指定节点的实例 srvctl start instance -d orcl -i orcl1 -- 启动数据库服务 srvctl start service -d orcl -s srv_app
CRS启动失败是RAC运维中最常见的故障之一，排查时应遵循自底向上的思路。首先确认ohasd是否存活，检查进程以及$GRID_HOME/log/节点名/ohasd目录下的ohasd.log；如果ohasd正常但crsd或cssd起不来，再分别查看crsd.log和ocssd.log。cssd相关的故障往往与心跳网络和投票磁盘有关，可以检查私网连通性，并通过crsctl query css votedisk确认投票磁盘的访问是否正常。
-- 检查cssd心跳和节点连通性 ocrcheck crsctl query css votedisk crsctl check crs crsctl check cluster -all -- 查看集群告警日志，定位最近的故障事件 -- 路径示例：/u01/app/grid/diag/crs/rac1/crs/trace/alert.log
还有一个实用技巧是利用Grid Infrastructure的自动诊断收集工具chmos或 diagcollection收集诊断包，同时GI的alert.log（位于GRID_HOME的diag/crs下）会以简洁的时间线记录资源的启停和故障事件，是快速定位问题时间点的第一手资料。掌握这些日志的位置和阅读方法，比盲目重启集群要有效得多。
总的来说，CRS是Oracle RAC高可用能力的实现核心，它通过cssd维护节点成员关系、通过crsd调度资源、通过故障转移策略保障业务连续性。深入理解ohasd、cssd、crsd、evmd各进程的职责以及资源的监控与转移机制，再配合crsctl和srvctl的熟练使用，DBA才能真正做到从容应对RAC环境中的各种异常场景，把集群的高可用设计价值充分发挥出来。
Oracle RAC集群就绪服务CRS修改时间：2026-09-02 10:39:48