什么情况停RAC单节点服务器，RAC单节点停机原因有哪些

RAC单节点服务器停机，通常发生在需要硬件维修、操作系统补丁升级或节点级故障排查时，而集群整体服务不受影响。这背后的逻辑并不复杂：Oracle RAC集群之所以存在，正是为了让单个节点的宕机不至于拖垮整个数据库服务，但“能停”和“该停”是两回事，下面直接拆解具体场景和判断标准。

RAC单节点停机维护的常用场景与操作窗口

停一个节点,本质上是让集群进入“降级运行”状态，什么时候干这件事风险最低、收益最大，是决定成败的关键。

什么情况停rac单节点服务器最安全

从运维实操角度来说,最安全的停机窗口具备三个特征：业务低峰期、剩余节点负载冗余充足、维护动作一次到位。

典型的安全场景包括：

• 硬件生命周期维护：内存条扩容、SSD固件升级、RAID卡电池更换、光模块清洁或替换，这些操作必须断电或重启才能完成，单节点停机是标准路径。
• 操作系统内核补丁：比如Linux kernel的安全更新或驱动修复，需要重启节点让新内核生效。
• Oracle补丁集或集群软件升级：GI（Grid Infrastructure）补丁打完通常要求重启节点上的CRS服务。
• 节点本地日志清理或文件系统扩容：例如/u01或/var分区写满，虽然在线也能处理，但某些情况下需要重启才能彻底释放句柄或重新挂载。
• 网络配置变更：修改公有网卡或私有网卡的绑定模式、IP地址调整，需要重启网络服务甚至节点。

这些场景的共同特点是：操作对象是节点本身，而非数据库业务，集群层面的ASM实例、监听、VIP资源都会在节点关闭后自动失败切换（Failover）到兄弟节点。

从故障现象反推停机必要性

很多时候不是“想停”，而是“不得不停”，遇到以下现象时，停单节点服务器是排查绕不开的路径：

• 节点私网通信频繁报错,crsctl check cluster 显示节点间心跳超时。
• alert_<实例名>.log 里大量ORA-00600或ORA-07445错误，且集中在某个进程或某个CPU核心上。
• 节点物理内存报ECC错误,需要更换内存条。
• 系统负载长期超高,但杀掉进程后依然无法恢复，怀疑操作系统层面资源泄露。

行业共识认为,如果业务侧已经感知到连接中断或响应缓慢，且错误日志指向节点本地资源，停掉该节点、切走流量”本身就是一种恢复手段，而不是简单的维护动作。

哪些情况不该贪图省事直接停RAC单节点

停单节点服务器虽然不像停整个集群那么伤筋动骨,但也有明确的操作红线，踩了这些坑，轻则服务闪断，重则导致RAC集群整体不可用。

剩余节点容量不足时强行停机

这是最常见的误判,很多DBA只看CPU负载，忽略了内存和IO能力。

假如一个双节点RAC,每个节点内存只有50%空闲，此时如果停掉其中一个节点，那么剩余节点要承接100%的连接池和会话，内存可能瞬间被撑爆，Oracle在内存不足时不会优雅排队，而是直接触发ORA-04031或引发swap抖动，最终导致集群两败俱伤。

停机前必须做一次容量预检：

-- 检查当前各实例的活动会话数
SELECT inst_id, COUNT() FROM gv$session WHERE status = 'ACTIVE' GROUP BY inst_id;
-- 检查共享池和缓冲池使用率
SELECT name, ROUND(bytes/1024/1024/1024, 2) AS size_gb FROM gv$sgastat WHERE name = 'buffer cache' AND inst_id = 1;

如果活动会话总和超过剩余节点可承载会话数的60%，就不要停，类似的检查还包括ASM磁盘组剩余空间，如果剩余空间无法容纳目标节点上的数据重平衡，同样不适合停机。

正在跑长事务或批量任务时停节点

长事务一旦被强制中断,代价不只是回滚那么简单，在RAC架构下，当一个节点上的事务正在修改数据块，而另一个节点恰好对同一数据块发起了请求，就会产生全局缓存（Global Cache）交互，此时停节点，所有未完成的分布式锁管理（DLM）操作都需要在剩余节点上重新建立，轻则卡顿数分钟，重则触发ORA-29740实例驱逐。

判断标准很直接：

• 巡检gv$transaction视图，如果有运行超过10分钟的事务，等它结束再操作。
• 检查gv$session中SQL_ID对应的执行计划，全表扫描大表且返回行数巨大的查询，优先停掉。

双节点ASM共享磁盘组处于高负载重平衡状态时

ASM会在添加或删除磁盘后自动做数据重平衡（Rebalance），如果你在重平衡尚未结束时停掉其中一个节点，ASM实例会感知到节点离线，并重新估算重平衡进度，这可能导致IO风暴持续更久，甚至影响所有节点的磁盘访问。

停单节点服务器的完整操作步骤与黄金检查清单

如果场景确认无误、窗口合适，就可以按以下流程操作，这套顺序是经过生产环境验证的标准路径，每一步都对应一个可验证的结果。

停机前两小时：业务层与集群层准备

1. 通知业务方：明确告知套路时间窗口、预计影响（无感或秒级闪断），请应用运维在服务端暂时摘除该节点的流量转发。
2. 检查集群整体状态：

   crsctl check cluster -all
   crsctl status resource -t

   确认所有资源都在online状态,两个节点都在running状态，没有正在进行的OCR备份或表决盘操作。

3. 评估服务资源分布：确保目标节点上的服务（Service）具备taf（透明故障切换）或fcf（快速连接故障切换）能力，如果是非RAC服务的单点资源，先手动将其迁移到其他节点。

停机前十五分钟：实例级收尾

1. 记录当前数据库的检查点（SCN），用于停机后对比是否正常推进。
2. 关闭目标节点的监听注册：

srvctl stop service -d <dbname> -s <service_name> -i <instance_name>

这一步只摘掉服务,不关闭实例，让新的连接请求不再路由到该节点。
3. 手动关闭目标实例

：

srvctl stop instance -d <dbname> -i <instance_name>

注意,不建议直接用shutdown abort，除非实例已经hang住，正常关闭会等待当前事务完成，并释放所有全局锁，这一步执行时间可能在几秒到几分钟之间，取决于活动会话数量。

4. 关闭节点上的数据库相关资源（如果只是重启服务器，跳这一步）：

   crsctl stop resource ora.<dbname>.db -n <nodename>

停机期间与启动后的验证

机器维护完成后,按逆序启动：

srvctl start instance -d <dbname> -i <instance_name>
srvctl start service -d <dbname> -s <service_name> -i <instance_name>

启动后必须做的验证动作：

• 查看alert日志，确认没有ORA-00600、ORA-29740等错误。
• 执行crsctl status resource -t，确认该节点上的VIP、ONS、ASM实例、数据库实例都已online。
• 在SQLPLUS中跑一次简单的表查询和一次DML提交，验证集群缓存融合功能正常，这一步比任何监控工具都直接。

rac单节点停机对业务的前台感知与隐性风险

很多甲方会问“rac重启单节点安全吗？会不会闪断连接？”答案取决于应用层配置。

连接池配置决定业务感知

如果应用使用UCP（Universal Connection Pool）、HikariCP或WebLogic的Active GridLink，配合FCF（Fast Connection Failover），在节点停机时能感知到事件并快速建立到新节点的连接，业务基本无感。

如果应用只配置了简单的JDBC URL指向DEFAULT实例，而监听资源随着节点关闭而offline，那所有直连该节点的应用都会报连接超时，这种情况下，即使数据库实例能正常存活，业务依然会中断。

停机前必须检查应用连接串：

• 是否使用SCAN Name而不是VIP。
• 连接属性中是否包含failover=on（查询接口协商）。
• 连接池配置的validate或者testOnBorrow周期是否超过30秒。

节点从集群中被驱逐的隐性风险

服务器重启后,CRS会自动将节点重新加入集群，但如果节点是断电重启，且该节点上有未写入表决盘（Voting File）的最新内存状态，系统会触发重新配置（Reconfiguration），在极端情况下，如果另一个节点的私网网卡也存在隐性老化，两者同时抖动，会加剧形成“两端互相驱逐”的死循环。

为规避此风险,操作流程中要额外加一条：在停节点前对剩余节点的私网进行连通性测试，例如用ping -c 100检查报文丢失率，如果丢包超过1%，说明私网物理链路有问题，先别停。

停机操作中的高频失误与对应规避方法

统计显示,相当一部分RAC节点重启后出现问题，根源是“启动顺序错误”，一定要等CRS自己拉起资源，不要手动crsctl start crs然后又去手动mount磁盘，这会造成资源归属混乱。

单节点服务器停机的补充：如何缩短停机时长

停机本质上是节点被移出集群

当停下一个节点的CRS服务时,Oracle Clusterware会将该节点标记为OFFLINE，并把该节点上的资源重新定位到其他节点，这个过程叫Reconfiguration，期间会短暂持有部分锁，时间通常在几秒内，对于双节点RAC，这个秒级窗口是真实存在的，但业务侧如果不依赖单点VIP，基本无感。

想进一步压缩停窗口期，采用滚动维护套路

如果业务方接受两次短暂抖动,可以分两步停：

1. 先停节点A的实例,做操作系统级别的部分维护（如网卡配置、文件系统扩容）。
2. 重启节点A,确认集群资源全部恢复online。
3. 再停节点B做同样的维护。

这种方式避免了双节点同时维护的真空期风险,适合对可用性要求极高的核心库。

Q&A：关于停RAC单节点服务器的常见疑问

停RAC单节点服务器需要停业务吗？

不需要停整个业务,但建议通知业务方，正常情况下，服务会切换到存活节点，已建立的连接会中断，新连接通过SCAN转发到存活节点，如果应用配置了TAF且使用Oracle Net的failover模式，部分查询可以自动重连，应用无感，但本地事务未提交的会话会报错，因此提前摘除流量、等待活动事务跑完是最稳妥的做法。

停RAC单节点后起不来回滚怎么办？

首先确认是否满足预期,节点启动时可能自动做实例恢复，耗时取决于需要回滚的事务规模，如果启动卡住，查看alert_<实例名>.log中的CKPT进程状态，若日志停在某个ORA-xxx错误上，不要重复重启节点，先检查ASM磁盘组是否能正常识别。

sqlplus / as sysasm
-- 检查磁盘挂载状态
SELECT group_number, disk_number, state FROM v$asm_disk WHERE mount_status = 'CACHED';

什么时间窗口最推荐？

绝大多数生产环境推荐在业务低峰期进行,比如凌晨1点到4点之间，这个时段恰好是日志切换和夜间备份后的间隙，也是应用定时任务相对较少的窗口，如果是金融或电商行业，双11或大型促销前一周内避免任何节点停机操作，这是行业共识，宁可提前或延后，也不要在大促前做变更。