asm磁盘io超时直接触发rac节点驱逐，因ocssd将超时视为节点失联硬信号，立即执行强制重启以防止脑裂；根因多在底层存储链路不可靠，如multipath切换失败、asmlib残留干扰afd、磁盘头元数据损坏、私网丢包叠加io延迟等。
ASM磁盘IO超时直接触发节点驱逐
Oracle RAC不是“报错后重试”，而是把IO超时当作节点健康失效的硬信号。一旦ocssd进程检测到某节点对OCR或voting disk的I/O响应超过默认60秒（_css_misscount隐含参数控制），就判定该节点失联，立即发起驱逐（eviction）。被驱逐节点上的oracssdagent收到指令后会主动触发主机重启——这是RAC防止脑裂的强制保护机制，不是系统崩溃，是设计行为。
IO超时背后的真实存储链路断裂
常见根因不在ASM层，而在底层设备路径不可靠：
- 多路径（multipath）切换失败：比如
mpathb在节点1走的是路径A，节点2却走路径B，其中一条链路中断后，ASMLib仍尝试访问已失效的/dev/sdb（而非/dev/mapper/mpathb），导致IO hang - ASMLib残留干扰AFD：若
lsmod | grep oracleasm有输出，说明ASMLib内核模块仍在运行，它会劫持I/O路径，绕过multipath和AFD的故障切换逻辑，使单点链路故障无法恢复 - 磁盘头元数据损坏：用
kfed read /dev/mapper/mpathb看到KFED-00322: Invalid OSM block type，说明ASMLib曾覆写磁盘头，破坏了ASMFD识别所需的AFD签名 - 私网丢包叠加IO延迟：OCSSD心跳依赖UDP 12345端口，若私网丢包率高，会放大IO等待时间，使原本可恢复的IO延迟被误判为永久性故障
为什么crsctl stat res -t看起来正常但实际已瘫痪
资源状态显示ONLINE只代表CRS试图启动过ora.asm，不代表ASM实例真能读写磁盘：
-
ora.asm进程存在，但v$asm_diskgroup里对应磁盘组状态是DISMOUNTED或查不到任何行 -
asmcmd lsdg返回空或报ORA-15032，但ps -ef | grep asm_pmon能看到进程——说明ASM实例起来了，只是无法访问底层设备 - 关键线索在
$GRID_HOME/log/<hostname>/cssd/ocssd.log</hostname>里反复出现IPC Send timeout或Failed to connect to CSS daemon，这往往意味着OCR磁盘组根本没挂上，CSS连不到自己的心跳盘
排查必须从存储设备层开始，不能只看数据库日志
数据库alert.log里一堆ORA-15064或ORA-29770只是结果，不是原因。真正要盯住的是：
- 所有节点执行
multipath -ll，确认OCR所在磁盘（如mpathc）的路径数、active状态是否一致；若有节点少两条路径，立刻查光纤交换机zone或HBA卡状态 - 用
dd if=/dev/zero of=/dev/mapper/mpathc bs=4k count=100 oflag=direct手动测裸设备写入延时，>500ms即危险 - 检查
/etc/multipath.conf中path_grouping_policy是否为multibus（非failover），否则多路径不生效 - 确认
asmcmd afd_lsdsk输出中OCR盘状态为a（available），而非?或空——?表示AFD无法解析设备，大概率是udev规则缺失或ASMLib残留
最易被忽略的是：节点间/dev/mapper/下设备名一致，但scsi_id -g -u -d /dev/sda输出的WWID不一致。这意味着multipath底层设备映射错位，AFD无法跨节点识别同一块盘，集群必然分裂。
