如何修复Oracle RAC中由于磁盘IO超时引起的节点挂起

crsctl命令卡住超30秒基本源于OCR磁盘I/O异常或SSH互信失效；需用dd和iostat实测OCR设备读速（顺序读≥80MB/s、随机读r_await<10ms、%util≤90%），并验证ssh -o StrictHostKeyChecking=no -o ConnectTimeout=5 oracle@rac2 date在5秒内响应，同时确保/home/oracle权限为700。

crsctl命令卡住超过30秒，基本就是磁盘IO或SSH问题

oracle rac中crsctl start crs、ocrcheck、crsctl query css votedisk等命令长时间无响应（光标不动、无报错、数分钟才返回），不是命令本身慢，而是底层强依赖被拖住。核心就两个：ocr磁盘读取是否正常，节点间ssh调用是否在5秒内完成。别先查日志，先测这两项。

实测OCR磁盘I/O速度：dd和iostat必须一起看

OCR不是普通文件，它是集群启动时同步校验的二进制注册表。单次4KB随机读延迟超50ms，crsctl start crs就会卡在CRS-4124或CRS-2672阶段。

• 先定位OCR设备路径：crsctl query css votedisk，找带+OCR或/dev/oracle/ocr01这类标识的行
• 若OCR在ASM磁盘组（如+OCR），必须先用asmcmd lsdg确认它对应哪些物理设备，再对具体设备测速；直接测ASM别名没意义
• 顺序读测试（模拟大块元数据加载）：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（应<10ms）、%util（长期>90%说明IO队列积压）

验证SSH互信是否真生效：/home/oracle权限比.ssh还关键

RAC内部调用SSH是带参数封装的：ssh -o StrictHostKeyChecking=no -o ConnectTimeout=5。很多DBA反复重配authorized_keys却失败，根本原因是/home/oracle权限不对——OpenSSH服务端默认拒绝755或775的家目录。

• 检查权限：ls -ld /home/oracle，若显示drwxr-xr-x（755）或drwxrwxr-x（775），立刻执行chmod 700 /home/oracle
• 同时确认：.ssh目录权限为700，authorized_keys为600，且属主是oracle:oinstall
• 验证方式不是ssh rac2，而是ssh -o StrictHostKeyChecking=no -o ConnectTimeout=5 oracle@rac2 date，必须在5秒内返回

节点已挂起时，别硬等crsctl返回

如果节点已假死（比如top卡住、ps无响应、系统日志出现end_request: I/O error, dev sdi或nfs: server not responding），crsctl不可能成功。此时强行执行只会浪费时间。

• 优先查dmesg | tail -50和/var/log/messages，确认是否有磁盘坏道、NFS超时、控制器故障等硬件级报错
• 若OCR放在NFS上，且服务端无响应，节点会被驱逐但无法自动重启——操作系统已卡在IO hang里，连kill -9都可能不生效
• 不要反复执行crsctl stop crs -f，改用root用户直接reboot -f或硬重启；重启后第一件事仍是测OCR设备和SSH延时

真实场景里，OCR磁盘I/O异常和SSH互信失效经常共存。修复时容易只盯一个点，结果换完磁盘发现还是卡——忘了/home/oracle权限早被其他运维改成了755。