OCR磁盘I/O异常或SSH互信失效会导致crsctl等命令卡住；需用dd/iostat实测OCR设备读速（应≥80MB/s），并验证ssh -o StrictHostKeyChecking=no -o ConnectTimeout=5调用是否5秒内响应，同时检查/home/oracle权限必须为700。
Grid命令执行卡在crsctl start crs或ocrcheck耗时超30秒
这基本不是命令本身的问题，而是底层依赖被拖慢了。oracle 19c rac的crsctl、ocrcheck、crsctl query css votedisk等命令启动时会强依赖ocr磁盘读取和节点间ssh通信。一旦其中任一环节延迟高，整个命令就会“挂住”。常见现象是光标不动、无报错、等待数分钟才返回，或直接超时失败。
排查要分两路并行：先确认OCR磁盘I/O是否真实异常，再验证SSH互信是否彻底生效。不能只看ssh oracle@rac2 date能通就认为没问题——RAC内部调用的是带-o StrictHostKeyChecking=no -o ConnectTimeout=5等参数的封装调用，对权限和响应时间更敏感。
检查OCR磁盘物理读取速度：别猜，用dd和iostat实测
OCR不是普通文件，它是集群启动时必须同步校验的二进制注册表。哪怕单次4KB随机读延迟超过50ms，crsctl start crs就可能卡在CRS-4124或CRS-2672阶段。
- 先定位OCR设备路径：
ocrconfig -showbackup或crsctl query css votedisk，输出里带+OCR或/dev/oracle/ocr01这类标识的才是目标 - 顺序读测试（模拟大块元数据加载）：
dd if=/dev/oracle/ocr01 of=/dev/null bs=1M count=1024 iflag=direct status=progress—— 理想值 ≥80MB/s（SATA SSD），低于30MB/s需立即干预 - 随机读压力观察：
iostat -x 1，重点关注r_await（应 %util（长期 > 90%说明IO队列积压）
注意：如果OCR放在ASM磁盘组（如+OCR），需先用asmcmd lsdg确认该磁盘组底层对应哪些物理设备，再对具体设备测速。跳过这步直接测ASM别名，结果毫无参考价值。
验证SSH互信是否真生效：/home/oracle权限比.ssh还关键
很多DBA反复重配.ssh/id_rsa.pub追加到authorized_keys，却始终失败。根本原因常藏在用户主目录权限里——/home/oracle必须是700，不能是755或775。OpenSSH服务端默认拒绝权限过松的家目录，而RAC的root.sh和crsctl内部调用正是基于此规则校验。
- 检查权限：
ls -ld /home/oracle，若显示drwxr-xr-x（即755）或drwxrwxr-x（775），立刻修复：chmod 700 /home/oracle - 同时确认
.ssh目录权限为700，authorized_keys为600，且属主是oracle:oinstall - 验证方式不是
ssh rac2，而是模拟RAC调用：ssh -o StrictHostKeyChecking=no -o ConnectTimeout=5 oracle@rac2 date，必须在5秒内返回且无密码提示
特别注意：/tmp/CVU_*目录残留也会干扰后续操作。若之前安装失败过，执行rm -rf /tmp/CVU_*并清空所有节点的/tmp下相关临时目录。
应急绕过校验启动CRS：仅限诊断，不可长期使用
当OCR磁盘确认异常且短时无法修复，又急需拉起集群做故障分析时，可用crsctl start crs -excl -nocrs强制以独占模式启动本地CRS服务。它跳过OCR读取和节点同步校验，让crsctl命令本身恢复响应。
- 该命令仅启动本节点的
ohasd和ora.cssd进程，不尝试连接其他节点，也不加载OCR/Voting Disk -
crsctl check crs会显示CRS-4639: Could not contact Oracle High Availability Services，属于预期行为 - 绝对不可用于生产环境长期运行——缺少OCR意味着集群无法做节点加入、资源故障转移、配置变更等任何协调动作
真正棘手的地方在于：OCR磁盘慢和SSH互信失效经常同时出现，但日志里不会明确告诉你哪个先坏。必须把dd测速和ssh -v调试当成固定动作，而不是等报错后再翻文档。
