必须先验证实例真正离线：srvctl status instance输出“is not running”，且v$thread中对应线程消失；否则crsctl stop crs会因ASM资源未释放而失败。
srvctl stop instance 后必须确认线程真正消失
只执行 srvctl stop instance -d PROD -i PROD2 不代表实例已从集群视角“下线”。OCR 里残留的实例记录会卡住后续操作，常见错误是立刻去停 CRS，结果发现 v$thread 还有线程、srvctl status instance -d PROD -i PROD2 返回 “is not running” 但状态未同步到集群层。
必须验证两件事：
- 运行
srvctl status instance -d PROD -i PROD2，输出应为 “instance PROD2 is not running”（注意不是 OFFLINE） - 连接
sqlplus / as sysdba执行select thread#, status from v$thread;，对应 thread 应完全不显示，或状态为CLOSED；若仍为OPEN或MOUNTED，需补执行alter database disable thread 2;（仅限归档模式且无活跃事务时）
跳过这步，crsctl stop crs 很可能卡在 ora.asm 资源上，报错 CRS-2501: Resource 'ora.asm' is still running。
crsctl stop crs 必须由 root 执行且不能用 cluster 替代
crsctl stop crs 是唯一合法的单节点集群服务关闭命令，但它有硬性前提：必须由 root 用户执行。oracle 或 grid 用户执行会直接报权限拒绝，不是“没效果”，而是根本走不到资源清理逻辑。
绝对不要用 crsctl stop cluster 替代——它本质是集群协调命令，只要 OCR 和投票盘可达，就会触发其他节点强制响应，轻则资源反复 restart，重则引发 CSSD 心跳超时、节点被驱逐。
执行后立即验证：
-
crsctl check crs应返回CRS-4639: Could not contact Oracle High Availability Services -
ps -ef | grep -E "(crsd|cssd|ohasd)"应无匹配进程
关机前必须 crsctl disable crs
物理关机前不执行 crsctl disable crs，下次开机时 crsctl start crs 会自动拉起，但此时网络、存储 LUN、私网链路往往尚未就绪。后果是资源反复启动失败、CSSD 报 misscount exceeded、OCR 日志里出现大量 reboot required 记录，甚至导致节点被踢出集群。
这步只能在本节点以 root 执行，且必须在 crsctl stop crs 成功之后、shutdown -h now 之前完成。顺序错了等于白做。
Flex ASM 环境下要先查 asmcmd lsct
如果 GI 版本 ≥12.2 且启用了 Flex ASM，本节点可能是其他节点的 ASM client。直接停 CRS 会导致那些节点因无法访问 ASM 而 panic。
务必在停实例后、停 CRS 前，以 grid 用户执行：
-
asmcmd lsct查看 client 列表 - 若本节点出现在 client 列表中（尤其当它是唯一 client），需先在其他节点上执行
srvctl modify asm -g <new_asm_diskgroup> -n <other_node></other_node></new_asm_diskgroup>迁移 client 依赖，或临时禁用该节点的 client 角色
这个检查点容易被忽略，但一旦出事，恢复时间远超硬件维护本身。
