crsctl check cluster 和 ocrcheck 是节点异常重启后首要检查项：前者若非 crs-4638 状态（如 crs-4639）表明 has 不可用，后者若报 prot-1 错误或 status: fail 则指向 ocr 损坏或 asm/磁盘组未就绪，需同步验证 asmcmd lsdg 与 crsctl check cluster -all 全节点结果。
查 crsctl check cluster 和 ocrcheck 是否报错
节点异常重启后，第一反应不是翻日志，而是快速确认集群健康状态。很多重启其实源于 CRS 层面已不可用，但系统还在强行维持——这时 crsctl check cluster 会直接返回 CRS-4638: Oracle High Availability Services is online 以外的状态，比如 CRS-4639: Could not contact Oracle High Availability Services；ocrcheck 若提示 PROT-1: Failed to initialize ocrconfig 或校验失败（Status: FAIL），基本可锁定 OCR 损坏或访问中断。
注意：crsctl check cluster -all 必须在所有节点执行，不能只看当前节点；OCR 文件路径通常为 +OCR_VOTE/OCRFILE，若 ASM 实例未启动或磁盘组 offline，ocrcheck 就会静默失败，需同步检查 asmcmd lsdg 输出。
看 ocssd.log 里是否有 reboot、evm 或 cssdagent 异常退出
ocssd.log 是定位 RAC 节点“心跳死亡”的核心日志，路径一般是 $GRID_HOME/log/<hostname>/cssd/ocssd.log</hostname>。重点搜三类线索：
-
reboot：不是指系统重启命令，而是 CSSD 自动触发的强制 reboot 动作，常见于Node evicted by node <x></x>后紧跟着Rebooting system due to eviction -
evm相关错误：如EVM daemon not responding，说明事件管理服务挂了，可能引发 CSSD 主动放弃节点 -
cssdagent崩溃堆栈：比如Segmentation fault (core dumped)或Failed to open /dev/oracleohas，往往指向 HAS 层权限或设备文件异常
别跳过时间戳比对：节点重启时间必须与 ocssd.log 中最后一条 ERROR 时间相差在 5 秒内，否则大概率是其他层（比如 OS panic）导致的连锁反应。
核对 systemctl status oracleohas 和 ps -ef | grep ohasd 状态是否一致
Oracle 12c+ 默认用 systemd 管理 OHAS 进程，但实际运行中常出现“systemd 显示 active，ps 却找不到 ohasd.bin”的假象。这是因为 oracleohas service 只负责拉起 ohasd，而 ohasd 自身崩溃后 systemd 不会自动重启它（默认 Restart=always 未启用）。
实操建议：
- 运行
systemctl status oracleohas，确认Active:行是active (running)，且Process:PID 与ps -ef | grep ohasd输出的 PID 一致 - 若不一致，立刻查
/var/log/messages中是否有ohasd failed with code 1或Permission denied on /dev/oracleohas - 检查
/etc/systemd/system/oracleohas.service是否被手动修改过RestartSec或禁用了Restart=always
排查 diskmon 和 asm 磁盘 I/O hang 导致的 CSSD timeout
这是最容易被忽略的深层根因：当 ASM 磁盘（尤其是 OCR/Voting Disk 所在磁盘组）遭遇底层存储响应超时（比如 SAN 链路抖动、LUN 队列满），CSSD 在等待 diskmon 返回心跳时会卡住，最终触发 eviction。现象是 ocssd.log 出现大量 clssnmWaitForAcks 超时，但没报具体磁盘名。
验证方式：
- 查
asmcmd lsdsk -k输出中是否有磁盘状态为UNKNOWN或PROVISIONED（非ONLINE） - 运行
strace -p $(pgrep -f "diskmon") -e trace=io_submit,io_getevents，观察是否长期阻塞在io_getevents - 对比同集群其他节点的
dmesg | tail -30，看是否有end_request: I/O error或timeout on device类似输出
真正的问题往往不在 Oracle 层，而在存储链路上——比如多路径软件（如 PowerPath 或 DM-Multipath）配置错误，导致某个路径静默丢包，CSSD 心跳探测恰好走到了那条坏路径上。
