CSSD卡在Voting Disk读写超时的根本原因是存储I/O在15秒内未响应，导致Oracle判定存储不可达；常见诱因包括多路径错乱、ASM磁盘头损坏或底层存储链路中断未恢复。
为什么 CSSD 卡在 Voting Disk 读写超时？
根本原因不是 cssd 本身坏了，而是它反复尝试访问 +asm 或裸设备上的投票盘（voting disk），但每次 i/o 都在 15s 内没返回——oracle 认定存储不可达，就拒绝继续启动。常见诱因是多路径错乱、asm 磁盘头损坏、或底层存储链路（hba/fc/san）临时中断后未恢复心跳。
crsctl check css 返回失败但节点没宕机？先看真实状态
这个命令只查本地 CSSD 进程是否存活，不反映投票盘可达性。真正要看的是：
-
crsctl query css votedisk—— 如果报ORA-15012: unable to locate file或直接卡住，说明 Voting Disk 元数据已不可见 -
ocrcheck -config—— 若也失败，大概率是同一套 ASM 磁盘组（通常是+OCR）一起挂了 -
ls -l /dev/oracleasm/disks/或blkid | grep oracleasm—— 检查磁盘设备节点是否存在且权限正确（属主应为grid:asmadmin）
多路径下 asmcmd lsdg 显示磁盘组 MOUNTED 但 CSSD 启不来？别信这个假象
ASM 实例能 mount 磁盘组，只代表它能读取磁盘头和 AU 0 的 ASM 元数据；而 CSSD 要求对 Voting Disk 执行持续、低延迟的同步写（比如更新节点心跳时间戳），这比 ASM 挂载严格得多。常见陷阱：
- 多路径策略设成
round-robin但某条路径实际断开，I/O 被调度到坏路径上，超时后才切到好路径——CSSD 等不及切换 - 存储侧开启了 QoS 限速，单次写入超过 500ms，触发 Oracle 默认的
disk_repair_time=14400误判 -
udev规则里用了SYMLINK+=但没加OWNER="grid"，导致 CSSD 以 root 身份打开设备失败（日志里藏在$GRID_HOME/log/<node>/cssd/ocssd.log的Permission denied）
紧急恢复：绕过 Voting Disk 强制启动 CSSD 的风险与操作
仅限排障用，不能长期运行。本质是让当前节点“假装”自己是唯一节点，跳过仲裁流程：
- 停止所有 CRS：
crsctl stop crs -f - 用
crsctl start crs -excl -nocrs启动 CSSD 独占模式（注意参数顺序，-excl必须在前） - 此时
crsctl query css votedisk会显示0个投票盘，crsctl check css变绿，但集群服务（CRS、OHAS）不会自动拉起 - 立刻查
ocssd.log里最近的IO timeout对应的设备名（如/dev/mapper/mpathb），然后针对性修复存储链路
真正麻烦的从来不是怎么绕过去，而是为什么那个设备在 dd if=/dev/zero of=/dev/mapper/mpathb bs=4k count=100 oflag=sync 下都慢过 2s——这说明问题不在 Oracle，而在你没盯紧的那层存储固件或交换机 zone 配置。
立即学习“前端免费学习笔记（深入）”；
