OCR磁盘IO异常会导致RAC启动卡在CRS-4124或CRS-2672阶段，需用dd和iostat实测读取速度，确认是否低于阈值；常见真因包括未启用多路径、ASM冗余模式错误及OCR被其他进程抢占；应急可执行crsctl start crs -excl -nocrs跳过校验。
OCR磁盘读取慢直接拖垮RAC启动
oracle rac启动卡在crs-4124或crs-2672阶段，且ocrcheck耗时超过30秒，基本可以判定是ocr磁盘io异常。ocr（oracle cluster registry）不是普通文件——它是rac集群的“心跳数据库”，所有节点启动时必须同步读取并验证ocr内容。哪怕只是单次读取延迟高，整个集群就无法完成初始化。
用dd和iostat确认OCR设备是否真慢
别猜，直接测物理读取速度。OCR通常位于ASM磁盘组（如+OCR）或裸设备（如/dev/oracle/ocr01），先定位设备路径：
ocrconfig -showbackup 或 crsctl query css votedisk 查出OCR所在磁盘设备名
然后分两步验证：
- 测顺序读：用
dd if=/dev/[设备名] of=/dev/null bs=1M count=1024 iflag=direct status=progress—— 理想值应 ≥80MB/s（SATA SSD）或 ≥300MB/s（NVMe）；低于30MB/s即危险 - 测随机读：用
iostat -x 1观察%util是否长期接近100%，同时r_await> 50ms说明I/O响应严重积压
常见但容易被忽略的OCR磁盘问题
很多DBA查完磁盘健康就停手了，其实以下三点才是高频真因：
- OCR放在共享存储但未启用多路径（multipath）：单路径故障或拥塞时，
crsd.bin会反复重试，导致启动超时。检查mpathconf --show和lsblk输出是否一致 - ASM磁盘组冗余模式不匹配：OCR要求
EXTERNAL REDUNDANCY，若误建为NORMAL，每次读取需跨多个failgroup校验，IO放大3倍以上 - OCR磁盘被其他进程抢占：比如备份任务、日志轮转脚本或监控工具频繁
stat()OCR文件。用lsof +D /dev/[设备名]可揪出元凶
临时绕过OCR读取加速启动（仅应急）
如果集群已宕机且业务急需恢复，可用强制本地启动跳过OCR校验（注意：仅限单节点临时救急）：
在目标节点执行：crsctl start crs -excl -nocrs
该命令让CRS以独占模式启动，不读OCR也不连其他节点，能快速拉起ora.crsd进程。之后再用ocrconfig -restore从最近备份恢复OCR，比干等慢盘读取更可控。
真正棘手的是OCR磁盘本身没问题，但权限或udev规则错配导致每次访问都触发SELinux拒绝或内核重试——这种问题不会报错，只会让ocrcheck静默卡住15秒以上。
