crsctl check cluster -all报OCR验证失败根本原因是ASM磁盘组未正常MOUNTED或OCR路径未被识别，需先检查ora.asm状态、确认OCR磁盘组MOUNTED且USABLE_FILE_MB>0、验证ocrcheck输出路径指向有效ASM磁盘组。
crsctl check cluster -all 报 OCR 验证失败
这是最典型的校验失败信号，错误里常带 OCR not configured 或 CRS-4256。根本不是 OCR 文件丢了，而是 ASM 磁盘组没起来，或者 OCR 所在磁盘组（通常是 +OCR）状态为 MOUNTED 但没被集群识别。
实操建议：
- 先确认 ASM 实例是否运行：
crsctl stat res ora.asm -w "STATE == ONLINE"；如果没 online，直接crsctl start res ora.asm - 检查 OCR 所在磁盘组是否真正可访问：
sqlplus / as sysasm→SELECT name, state FROM v$asm_diskgroup WHERE name = 'OCR';，必须是MOUNTED且USABLE_FILE_MB > 0 - 验证 OCR 物理位置是否被正确注册：
ocrcheck输出里的Device/File Name必须指向一个已 mount 的 ASM 磁盘组路径（如+OCR），不能是裸设备或本地文件系统 - 若
ocrcheck直接报错PROT-1，说明 OCR 设备不可达，立刻查crsctl stat res -t | grep ocr看ora.cluster_interconnect.haip和ora.asm是否都 online
runcluvfy.sh 预检卡住或静默退出
图形界面的 gridSetup.sh 在“Performing pre-checks”阶段不动，或命令行执行 runcluvfy.sh 后无输出就退出，说明预检脚本内部已失败，只是没把错误打出来。
实操建议：
- 别信界面提示，直接翻日志：
ls -t /tmp/GridSetupActions*.log | head -1，然后grep -i "failed\|error\|check" /tmp/GridSetupActions*.log - 常见堵点是节点间时间不同步、
/etc/hosts解析不一致（尤其 SCAN VIP 和节点 VIP）、NTP 服务未启用或 drift 超过 1 秒 - 手动复现关键检查项：
cluvfy comp clocksync -n all -verbose、cluvfy comp nodecon -n all -verbose，这两条会明确告诉你哪台机器 ping 不通、端口不通、SSH 免密失效 - 注意：预检默认用
oracle用户跑，但某些检查（如磁盘权限）实际依赖grid用户上下文，切用户再试一次
olsnodes -s 显示节点状态为 Inactive
olsnodes -s 返回某节点状态是 Inactive，说明该节点的 OHASD（Oracle High Availability Services Daemon）根本没起来，集群层连“呼吸”都没有，后续所有验证全是空谈。
实操建议：
- 登录该节点，以
root身份执行：crsctl check crs—— 如果报CRS-4639: Could not contact Oracle High Availability Services，说明 OHASD 进程不存在 - 检查
/var/log/oracle/crsd/crsd.log开头几行，大概率能看到Unable to open OCR file或Failed to initialize CSS，根源还是 OCR 或 voting disk 不可达 - 强制启动 OHASD：
crsctl start crs；若失败，看/var/log/oracle/ohasd/ohasd.log，重点关注 CSSD 进程启动时是否因网络心跳超时被 kill - 检查网卡绑定和私网配置：
ifconfig确认私网接口（如 eth1）UP 且有地址；ping -I eth1 对端私网IP必须通，且iptables -L | grep 12345确保集群通信端口没被拦
srvctl status listener 报 “Listener is enabled but not running”
监听器显示 enabled 但 not running，表面是监听问题，深层往往是 SCAN 名称解析失败或 GNS（Grid Naming Service）未接管，导致 srvctl 根本无法定位监听资源归属。
实操建议：
- 先确认 SCAN 名是否能被所有节点解析：
nslookup myscan.example.com，必须返回 3 个 A 记录，且每个 IP 都能telnet <scan_ip> 1521</scan_ip>通 - 检查 SCAN 监听资源是否注册：
crsctl stat res -t | grep scan，应看到ora.LISTENER_SCAN1.lsnr等资源，状态为ONLINE；若为OFFLINE，执行srvctl start scan - 监听日志里搜
TNS-12545或no such host，大概率是$GRID_HOME/network/admin/listener.ora中的HOST值写成了主机名而非 SCAN 名，或endpoints_listener.ora里端口冲突 - 重启监听前务必停掉 GNS：
srvctl stop gns，否则新起的监听可能又被 GNS 强制重配
crsctl stat res -t 输出里那几行红色 OFFLINE，它们就是故障链的起点。 
