必须按依赖顺序停资源：先srvctl stop instance并验证v$thread线程消失，再root执行crsctl stop crs，关机前务必crsctl disable crs，否则重启后易引发ocr异常或节点驱逐。
能关，但必须按依赖顺序停资源，否则其他节点可能被误驱逐或OCR状态异常。
srvctl stop instance 之后必须确认实例真正离线
只执行 srvctl stop instance -d PROD -i PROD2 不代表实例已从集群视角“消失”。常见错误是立刻去停 CRS，结果发现 v$thread 还有线程、srvctl status database -d PROD 显示状态为 OFFLINE 而非 STOPPED，说明 OCR 里该实例记录未清理干净。
- 停实例后立即查：
srvctl status instance -d PROD -i PROD2，输出应为 “instance PROD2 is not running” - 再查：
select thread#, status from v$thread;，对应线程应已消失 - 若仍显示
OPEN或卡在MOUNTED，需补sqlplus / as sysdba手动alter database disable thread 2;（仅限归档模式且无活动事务时） - 别跳过这步——残留线程会导致后续
crsctl stop crs拒绝停止 ASM，报错CRS-2501: Resource 'ora.asm' is still running
crsctl stop crs 必须在本节点以 root 执行，不能用 crsctl stop cluster
crsctl stop cluster 是集群级命令，只要 OCR 和投票盘可达，它会触发所有节点的强制 shutdown，不是“关一个节点”，而是“关整个 RAC”。真要单节点维护，唯一合法操作是 crsctl stop crs，但它有硬性前提：
- 必须由
root用户执行（oracle或grid用户会报权限拒绝） - 执行前确保本节点没运行任何被其他节点依赖的资源（如 Flex ASM client、SCAN listener）
- 若 GI 版本 ≥12.2 且启用了 Flex ASM，先确认本节点不是当前唯一 ASM client：
asmcmd lsct查 client 列表 - 执行后立刻验证：
crsctl check crs应报CRS-4639: Could not contact Oracle High Availability Services，这是正常现象；ps -ef | grep -E "(crsd|cssd|ohasd)"应无相关进程
关机前必须 disable crs 自启动，重启后才能避免自动拉起故障节点
节点物理关机前不 disable CRS，下次开机时 crsctl start crs 会自动执行，但此时网络、存储可能未就绪，导致资源反复 restart 失败、CSSD 心跳超时、甚至被其他节点 evict。这不是理论风险，是 OCR 日志里高频出现的 misscount exceeded 根源。
- 在本节点
root用户下执行：crsctl disable crs - 再执行关机命令：
shutdown -h now或poweroff - 硬件维护完成后，开机前确认：交换机端口 up、存储 LUN 可见、私网网卡 link 正常
- 开机后，先以
root执行crsctl enable crs，再crsctl start crs，等crsctl check cluster -all显示本节点状态为ONLINE后，再启动实例
最易被忽略的是：停 CRS 后不 disable 自启动，以及停实例后不验证 v$thread 状态。这两步漏掉，轻则维护后节点无法加入集群，重则 OCR 投票盘标记异常，需要手动 crsctl replace votedisk 恢复——那已经不是维护，是事故响应了。
