CRS-4535错误表明本地CRS进程链路中断，应先检查ohasd进程存活状态，再结合crsd.log中ORA-29701或OCR device不可访问等关键日志定位根因，而非直接重启整个集群栈。
crsctl check crs 返回异常时怎么快速定位
只要 crsctl check crs 报错（比如 CRS-4638: Oracle High Availability Services is online 但后面跟 CRS-4535: Cannot communicate with Cluster Ready Services），说明本地节点的 CRS 进程链路已断，别急着重启整个 stack。先确认本节点的 ohasd 是否存活：
ps -ef | grep ohasd
如果没进程，再查 /var/log/oracle/crsd/crsd.log 最近 20 行是否有 ORA-29701（无法连接 GNS）或 OCR device not accessible —— 前者大概率是网络或 GNS VIP 漂移问题，后者优先检查 ASM 磁盘组是否 mounted、+OCR 别名是否指向有效 diskgroup。
ocrcheck 和 ocrdump 输出怎么看关键信息
ocrcheck 不只是看 “Status: HEALTHY”，更要盯住 Version 和 Device/File Name：如果版本号不一致（如一个节点显示 12.2.0.1.0，另一个是 12.1.0.2.0），说明 OCR 升级未完成或部分节点未执行 rootupgrade.sh；若 Device/File Name 显示的是裸设备路径（如 /dev/raw/raw1）而非 ASM diskgroup（如 +OCR），说明还没迁移到 ASM 托管，这种配置在 12c+ 已不推荐，后续打补丁易出错。运行 ocrdump -stdout -keyname SYSTEM.CRS.VOTEDISK 可直接看到投票盘状态，输出里出现 STATE=ONLINE 才算真正在线，哪怕 voting disk 数量显示 3 个，只要其中任一 STATE=OFFLINE，集群就处于降级运行状态。
srvctl status 命令对不同资源类型要加什么参数
srvctl status 默认只查数据库实例，不查监听器或服务，容易漏掉关键故障点。
- 查监听器必须加
- 查 SCAN VIP 要用
srvctl status scan，不是srvctl status vip； - 查特定服务（比如业务用的
app_svc）得写全名并指定数据库：srvctl status service -d orcl -s app_svc； - 查 ASM 实例不能省略
-o参数，否则报错：srvctl status asm -n racnode1会失败，正确是srvctl status asm -n racnode1 -o +ASM1（其中+ASM1是 ASM 实例名）。如何用 crs_stat -t 避开过时陷阱
OCR 文件损坏、投票盘不可写、节点间心跳超时这三类问题往往不会立刻触发告警，但会在crs_stat -t在 12.1 及以后已被标记为 deprecated，输出字段含义模糊（比如ONLINE状态可能只是资源 agent 启动了，不代表服务真正可用）。实际排障中更应依赖crsctl stat res -t -w "TYPE = ora.database.type"这类带过滤的查询，它能精确区分STATE（当前 agent 状态）和TARGET（期望状态），当两者不一致时（如TARGET=ONLINE但STATE=OFFLINE），说明资源启动失败且未自动重试。另外注意：该命令默认只显示本地节点资源，跨节点状态需加-all参数，否则可能误判远程节点数据库已宕机。crsctl query css votedisk或cluvfy comp health的输出里留下细微异常——比如投票盘Required Voting Disks: 3但Active Voting Disks: 2，这种差值就是隐患起点。
-l：例如 srvctl status listener -l LISTENER_SCAN1；
