Oracle RAC（Real Application Clusters）集群由多个节点、多组服务和多层软件组件构成，停止操作远比单机数据库复杂。不少DBA在维护窗口中因为停止顺序不当，导致资源状态残留、CRS无法正常关闭，甚至需要强制终止进程。事实上，RAC的关闭是有明确层次关系的：先停业务层，再停数据库层，最后停集群件层。本文将按照从上到下的顺序，完整梳理RAC集群的停止流程、常用命令以及每一层的检查要点。
一、理解RAC集群的组件层次
在动手停止集群之前，必须先清楚RAC的软件栈结构。从下往上依次是：操作系统和网络层、Grid Infrastructure集群件层（包括CRS、OHASD、CSS、CRSD、EVMD等守护进程）、ASM实例层、数据库实例层，最上面是监听器、服务和客户端连接。
停止顺序之所以要自上而下，是因为集群件层（尤其是CRS和CSS）负责管理上层的所有资源。如果先停集群件，数据库实例、ASM实例和监听器会被强制终止，相当于执行了abort方式的关闭，可能造成事务回滚不完整、 redo 应用异常等问题，下次启动时还需要实例恢复，延长了启动时间。
另外要区分两个概念：crsctl stop cluster（或11.2之前的crsctl stop crs）停止的是单个节点或多个节点的集群件，而crsctl stop cluster -all可以一次性停止所有节点的CRS。srvctl stop database则只停止数据库实例，不影响集群件本身。理解这些命令的作用范围，才能灵活组合出正确的停止流程。
二、停止前的检查与准备工作
停止集群前建议先做一轮状态检查，确认当前资源运行情况，避免漏停或在异常状态下直接关闭。首先检查数据库实例和服务状态：
srvctl status database -d orcl srvctl status service -d orcl crsctl stat res -t
通过crsctl stat res -t可以完整看到所有集群资源的状态，包括数据库、监听器、SCAN、VIP、ASM磁盘组等，输出内容较长时建议保存到日志文件中留档。同时检查活动会话和长事务：
SELECT inst_id, username, COUNT(*) FROM gv$session WHERE type != 'BACKGROUND' GROUP BY inst_id, username; SELECT sid, serial#, start_time FROM v$transaction;
如果有长事务正在执行，需要与业务方确认是否等待其完成。应用侧也应提前切换或断开连接，比如关闭中间件连接池、停止应用服务器，避免停止数据库时大量报错日志。此外，确认归档空间和闪回区状态正常，避免停止过程中因空间问题产生告警。
三、正确的停止顺序与具体命令
标准的RAC全集群停止流程分为四步：停应用与业务、停数据库实例、停监听与服务（可并入上一步）、停集群件。下面逐步展开。
第一步，通知业务侧停止应用，释放到数据库的连接。第二步，停止整个数据库，推荐使用srvctl统一操作，它会按照依赖关系先停服务再停实例：
# 正常方式停止数据库（所有实例） srvctl stop database -d orcl # 需要立即断开会话时使用immediate方式 srvctl stop database -d orcl -o immediate # 只停止单个实例 srvctl stop instance -d orcl -i orcl1 -o immediate
第三步，确认监听器和SCAN监听状态。正常情况下srvctl stop database不会停止监听器，监听可以随集群件一起停止，也可以单独停止：srvctl stop listener和srvctl stop scan_listener。第四步，停止集群件，有两种粒度可选：
# 在任一节点执行，停止所有节点的集群栈 crsctl stop cluster -all # 只停止当前节点的集群栈（等同于11.2之前的crsctl stop crs） crsctl stop crs
执行crsctl stop cluster -all时，CSS会协调各节点同步关闭，避免脑裂判定。所有节点执行完成后，用crsctl check cluster确认输出显示无法连接CRS，即代表集群栈已经完全停止。如果操作系统也要关机维护，此时再执行shutdown命令才是安全的。
四、异常情况处理与常见误区
实际操作中经常遇到crsctl stop crs长时间挂起的情况，常见原因是某个资源停止脚本卡住，比如数据库shutdown normal在等待会话退出、ASM实例被锁定等。这时可以先用crsctl stat res -t定位处于INTERMEDIATE或OFFLINE过渡状态的资源，再针对性地处理，比如手动登录数据库执行shutdown immediate，而不是直接加-f参数强制停止集群。
crsctl stop crs -f会强制终止所有集群进程，虽然最终能达到停止目的，但相当于给数据库做了abort关闭，实例恢复会在下次启动时进行，生产环境应尽量避免。只有在集群已经卡死、常规手段无效时才作为最后选择，使用后要检查告警日志确认无资源残留。
另一个常见误区是把操作系统关机当成第一步直接执行。操作系统shutdown虽然会触发CRS的清理脚本，但如果清理超时，进程可能被强制杀死，留下不一致状态。规范做法永远是先停数据库、再停CRS、最后关系统。此外，对于打补丁场景，通常只需要停止需要维护的节点（crsctl stop crs在该节点执行），滚动方式操作，其他节点继续承载业务，这也是RAC高可用设计带来的优势。
五、停止后的验证
集群停止完成后，还应做最后确认：检查集群进程是否残留，ps -ef | grep cssd、ps -ef | grep crsd等命令不应再有输出（root脚本除外）；检查磁盘组和ASM实例已随集群关闭；如果涉及操作系统维护，确认/etc/oracle/scls_scr目录下的节点状态文件正常。这些验证步骤虽然简单，却能在重启集群时省去大量排障时间，是规范运维不可省略的收尾动作。
Oracle RAC集群停止顺序CRS服务修改时间：2026-09-01 20:34:37