crsctl stop cluster -all 从当前节点起，按 olsnodes -n 输出的OCR节点序号顺序逐个停止；start cluster -all 则按依赖链启动：ohasd→cssd→diskmon→crsd及托管资源，各节点内严格依赖、节点间并行。
crsctl stop cluster -all 会按什么顺序停服务？
它不是“同时”停所有节点，而是从当前执行命令的节点开始，按集群注册的节点顺序逐个发起停止请求。实际停机顺序取决于 olsnodes -n 输出的节点编号顺序（即 ocr 中记录的启动序），而非物理连接或主机名字典序。
常见错误现象：CRS-4639: Could not contact Oracle High Availability Services 出现在某节点上，往往是因为前一个节点已关停 CRS，导致后续节点无法通信 —— 这不是失败，是预期中的级联中断。
- 必须在已有 CRS 正常运行的节点上执行，否则
-all会直接报错退出 - 若某节点 CRS 已 hang 住，
stop cluster -all会在该节点超时（默认 5 分钟）后跳过，继续停其他节点 - 停机过程不等待数据库实例关闭完成，只确保 ASM 和 CRS 资源离线；实例可能仍在做 instance recovery，属正常
crsctl start cluster -all 的启动依赖链是什么？
它强制按 OCR 中定义的依赖关系启动：先启每个节点的 ohasd → 再启 ora.cssd → 然后 ora.diskmon（如启用）→ 最后并行拉起 ora.crsd 及其托管资源（包括 ASM、DB、VIP 等）。
关键点在于：start cluster -all 不等前一节点完全就绪才启下一节点，但每个节点内部严格遵循依赖顺序。若某节点 CSSD 启动失败，该节点 CRSD 不会尝试启动，但其他节点不受影响。
- 启动失败最常见于磁盘心跳丢失（
CRS-4678: Failed to start resource ora.cssd），需检查 ASM diskstring、udev 权限、多路径状态 - 不要在未确认
crsctl check cluster -all全绿前，手动用srvctl start database强启实例，否则可能触发资源冲突 -
ora.asm必须先 online，ora.dbname.db才能启动；强行跳过会导致 DB 注册失败、实例无法挂载
为什么有时 stop/start cluster -all 看似成功，但数据库连不上？
因为 crsctl 只管 CRS 栈本身是否 up/down，不管应用层服务是否 ready。常见脱节点在监听器和 SCAN VIP：它们虽被 CRS 管理，但启动耗时长于 CRSD，且依赖网络栈就绪。
典型表现：crsctl check cluster -all 返回 SUCCESS，但 lsnrctl status LISTENER_SCAN1 显示 “TNS-12541: TNS:no listener”，或 sqlplus /@mydb 报 “ORA-12545: Connect failed because target host or object does not exist”。
- SCAN VIP 默认由
ora.scan1.vip资源管理，它依赖公网网卡 UP 和 DNS 解析有效；DNS 慢或 /etc/hosts 缺失条目会导致延迟上线 - 监听器启动依赖
ora.LISTENER.lsnr资源，该资源又依赖对应节点的ora.net1.network；若私网配置异常，监听器可能卡在 INIT 状态 - 执行完
start cluster -all后，建议等 2–3 分钟再验证业务连接，或用crsctl stat res -t | grep -E "(LISTENER|SCAN|VIP)"确认关键网络资源状态为 ONLINE
有没有比 -all 更可控的重启方式？
有。生产环境更推荐分步操作：先单节点滚动停启，再全局校验。尤其当集群含 4+ 节点或存在跨版本升级痕迹时，-all 容易掩盖单点问题。
真正容易被忽略的是 OCR 和 voting disk 的 I/O 健康度 —— crsctl 不检测底层存储延迟。一次看似成功的 start cluster -all 后，如果 ASM 实例反复 offline，大概率是 voting disk 所在 LUN 出现间歇性超时，而非 CRS 配置问题。
- 滚动重启示例：
crsctl stop cluster -n node1→ 等crsctl check cluster -n node1失败 →crsctl start cluster -n node1→ 等crsctl check cluster -n node1成功 → 重复至所有节点 - 每次启完一个节点，立刻跑
asmcmd lsdg和srvctl status database -d mydb，比等全部启完再查更早暴露 ASM mount 或 DB startup 卡点 - 执行前务必确认
crsctl query css votedisk和ocrcheck均无 error；这两项异常时，-all操作可能引发脑裂或 OCR 损坏
