必须按顺序执行srvctl stop instance→crsctl stop res（vip/监听器/ons）→srvctl stop asm→crsctl stop cluster，否则会导致ocr/voting disk损坏、vip未释放、监听器残留及集群启动失败。
不能靠“限制访问”代替停机流程——srvctl stop instance 只停数据库进程，不释放 vip、监听器、asm 或集群资源，直接关机大概率导致 ocr/voting disk 损坏。
srvctl stop instance 后为什么客户端还能连上？
执行 srvctl stop instance -d orcl -i orcl1 仅终止指定实例的 PMON/LMON 等后台进程，但该节点上的以下资源仍运行：
-
ora.rac1.vip未释放，客户端 DNS 或 hosts 解析到该 VIP 仍会尝试连接 -
ora.rac1.lsnr仍在监听 1521 端口，新连接被接受后因无实例响应而超时或报 ORA-12514 -
ora.rac1.ons和ora.rac1.gsd继续广播事件，可能干扰其他节点服务迁移判断 - 若该节点是 ASM 主节点（
srvctl config asm -n rac1显示ASM instance +ASM1），磁盘组可能无法被其他节点正常挂载
为什么不能跳过 nodeapps 直接关机？
srvctl stop nodeapps -n rac1 在 12c+ 中已弃用，但它的功能不可跳过。若不手动清理对应资源，关机后会出现：
- OCR 中 VIP 资源状态卡在 INTERMEDIATE，下次
crsctl start crs失败并报 CRS-4639 -
crs_stat -t显示ora.rac1.vip为 OFFLINE，但实际 IP 仍绑定在网卡上，引发网络冲突 - 监听器残留端口占用，重启 CRS 时
ora.rac1.lsnr启动失败，报 TNS-12545 - 必须改用
crsctl stop res "ora.rac1.vip" "ora.rac1.ons" "ora.rac1.listener"逐个停掉，顺序不能乱：VIP → listener → ONS
停 ASM 前必须确认什么？
ASM 实例不是独立服务，它和磁盘组、数据库实例强耦合。强行停 srvctl stop asm -n rac1 会导致：
- 其他节点访问同一磁盘组时报 ORA-15064 / ORA-15080（通信中断）
- 若该节点是 voting disk 所在位置（
crsctl query css votedisk输出含 rac1），整个集群心跳丢失，触发 panic reboot - 必须先确保：
crsctl check cluster -n rac1返回 “CRS-4537: Cluster Ready Services is online”，且srvctl status database -d orcl显示所有实例已在其他节点 RUNNING - 再执行
srvctl stop asm -n rac1 -f（加-f是因 ASM 可能被 DB 实例 hold 住）
crsctl stop cluster 是唯一安全的最后一步
所有上层资源停完后，必须由 root 执行 crsctl stop cluster -n rac1，原因：
-
/etc/init.d/init.crs stop已过时，在 12c+ 中直接忽略 OCR 配置，只杀进程不清理共享内存段 -
crsctl stop crs仅停本地 CRS 进程，但不等待 CSSD、CRSD 完全退出，可能遗留ocssd.bin残留进程 -
crsctl stop cluster -n rac1会触发完整的 shutdown 序列：CRSD → CSSD → EVMD → OCSSD，并同步更新 voting disk 时间戳 - 执行后检查：
ps -ef | grep ora_应无任何ora_*进程，crsctl check cluster -n rac1报 CRS-4639（not running）才算真正干净
最容易被忽略的是：停完所有资源后，没等 crsctl check cluster -n rac1 明确返回 “not running” 就直接断电——此时 CSSD 可能还在刷 voting disk 日志，下一次启动时 OCR checksum 校验失败，只能从备份恢复。
