olsnodes -s -t 是判断RAC节点物理在线状态的最快命令，仅依赖OCR和ohasd进程，不依赖CRS资源；crsctl stat res -t 用于检查资源层健康，需重点关注STATE、TARGET、HOST三列。
直接看节点在线状态：用 olsnodes 最快
olsnodes 是 oracle rac 里查“哪些节点物理上还活着、被集群识别”的最轻量命令。它不依赖 crs 资源状态，只读 ocr 和本地 ohasd 进程，所以即使 crs 挂了，只要节点操作系统和 oracle 集群栈底层还在跑，它通常还能返回结果。
- 执行
olsnodes -s -t：显示节点名 + 状态（Active或Inactive）+ 类型（Hub/Leaf），这是日常巡检第一眼该看的 - 如果报错
PRCZ-2015 : Cannot communicate with crsd，说明crsd.bin进程已死，但别急着 reboot —— 先确认ohasd是否在运行（ps -ef | grep ohasd） - 注意：
olsnodes不显示 VIP、监听器或数据库实例状态，它只回答“这个机器算不算 RAC 集群的一员”
查资源级健康状况：必须用 crsctl stat res -t
当 olsnodes 显示所有节点都是 Active，但应用连不上数据库或 SCAN VIP 飘走，问题一定出在 CRS 管理的资源层。crsctl stat res -t 是唯一能一次性看清整个资源拓扑和当前状态的命令。
- 重点盯三列：
STATE（是否 ONLINE）、TARGET（是否 ENABLED）、HOST（是否在预期节点上运行）；比如ora.LISTENER_SCAN1.lsnr的STATE是OFFLINE，就说明 SCAN 监听器没起来 - 加
-w参数（如crsctl stat res -t -w "state eq 'OFFLINE'"）可过滤异常资源，避免人工扫屏漏掉隐藏的 OFFLINE 条目 - 如果某资源反复在两个节点间
INTERMEDIATE → OFFLINE → ONLINE切换，大概率是网络心跳丢包或 OCR 存储路径权限异常，不是简单crsctl start res能解决的
常见假阳性：节点“在线”但实际不可用
有时 olsnodes 和 crsctl stat res -t 都显示正常，但客户端连接超时、tnsping SCAN VIP 失败——这往往不是集群状态问题，而是网络或配置层面的“静默故障”。
- 检查 SCAN VIP 是否真在某个节点上绑定了：在每个节点执行
ip addr show | grep -A2 "scope global"，确认对应 SCAN VIP 出现在网卡上（不是仅出现在ifconfig -a的虚拟别名里） - 验证 DNS 解析一致性：所有节点执行
nslookup <your-scan-name>，必须返回**完全相同**的三个 IP，且顺序不能轮询错乱（Oracle 要求严格顺序匹配） -
srvctl config scan和srvctl config scan_listener输出的端口、协议要与lsnrctl status LISTENER_SCAN1实际监听的完全一致；常见坑是 SCAN 监听器监听了1521，但数据库服务注册的是1522，导致服务不可见
诊断链路断在哪：从底层往上捋
RAC 节点失联从来不是单点故障，而是一条依赖链断裂的结果。按顺序排查比瞎试更省时间。
- 先确认操作系统级通信：在 node1 上
ping node2、ssh node2 date、telnet node2 6200（默认 clusterware 通信端口），任一失败，olsnodes就会不准 - 再查集群栈进程：
crsctl check crs返回CRS-4638: Oracle High Availability Services is online才算基础可用；若提示CRS-4639: Could not contact Oracle High Availability Services，说明ohasd没起来，得去/var/log/oracle/crsd/crsd.log看初始化失败原因 - 最后才动资源：
crsctl stop res ora.cssd -f这类操作风险极高，除非明确知道 CSSD 异常且无其他节点可接管，否则不要手动干预核心守护进程
真正麻烦的不是命令不会敲，而是看到 ONLINE 就以为万事大吉。OCR 冗余损坏、ASM diskgroup mount 慢到超时、甚至 NTP 偏移超过 20 秒，都可能让节点“看似在线，实则被踢出投票”。多看日志，少信状态栏。
