根本原因是asmlib扫描单路径sd盘而非多路径mpath/dm设备，SAN路径中断导致I/O hang触发内核panic重启；需验证设备指向、修正SCANORDER/SCANEXCLUDE配置，并执行oracleasm scandisks刷新映射。
为什么asmlib扫描sd盘会导致RAC双节点重启
根本原因不是存储本身故障，而是asmlib在启动时扫描了单路径设备（如sd*），而没识别到多路径聚合后的mpath*或dm-*设备。一旦san维护断掉那条被asmlib实际绑定的sd路径，asm就立刻失去磁盘访问能力——i/o hang触发linux内核panic，最终强制重启节点。
典型现象包括：ocssd.log里反复出现missed heartbeat、eviction；dmesg -T能看到I/O error或device offline；ls -l /dev/oracleasm/disks/显示ASM disk指向/dev/sdb这类原始路径而非/dev/mapper/mpatha。
-
ORACLEASM_SCANORDER为空或未包含mpath和dm，导致默认优先扫sd* -
ORACLEASM_SCANEXCLUDE没排除sd，让单路径盘“合法”进入ASM识别范围 - 修改配置后未执行
oracleasm scandisks，新规则不生效
修复前必须确认的三件事
别急着改配置或重启服务。先验证当前ASM磁盘是否真由单路径设备承载：
- 运行
ls -l /dev/oracleasm/disks/，看每个disk link指向的是/dev/sdX还是/dev/mapper/mpath* - 执行
multipath -ll，确认关键ASM磁盘（如OCR/VOTE盘）确实有多个active路径 - 检查
/etc/sysconfig/oracleasm中ORACLEASM_SCANORDER和ORACLEASM_SCANEXCLUDE是否已按需设置——正确值应为ORACLEASM_SCANORDER="mpath dm"和ORACLEASM_SCANEXCLUDE="sd"
如果ls -l结果仍指向sd*，说明旧扫描结果还在缓存，必须清空并重扫，否则改配置无效。
如何安全重置asmlib磁盘识别
不能直接oracleasm deletedisk再createdisk——OCR/VOTEDISK磁盘一旦误删，集群将彻底不可用。正确做法是保留原有ASM标记，只刷新设备映射：
- 以root执行
oracleasm scandisks（注意：不是force-scandisks，后者会清空所有disk注册） - 执行
oracleasm listdisks，确认输出中的disk名与ls -l /dev/oracleasm/disks/指向的设备一致且为mpath*或dm-* - 若仍有
sd*残留，手动oracleasm deletedisk <DISK_NAME>（仅对非OCR/VOTE盘），再oracleasm createdisk指定/dev/mapper/mpathX路径 - 最后运行
crsctl check crs，等所有资源回到ONLINE状态再启动数据库实例
特别注意：oracleasm scandisks不会改变ASM disk上的标签，只更新/dev/oracleasm/disks/下的软链目标，这是最稳妥的修复动作。
为什么srvctl start nodeapps在11gR2后完全失效
因为从11.2.0.2起，VIP、ONS、GSD这些节点级网络资源已由Clusterware统一托管，srvctl start nodeapps命令本身已被移除。强行调用会报PRCR-1076或“command not found”。此时若节点网络异常，真正该做的是：
- 先确认
crsctl check crs返回CRS-4638（HA服务在线），否则用crsctl start crs（root权限）拉起OHAS - 检查
crsctl stat res -t | grep vip，看VIP资源是否为OFFLINE——若是，Clusterware会在几秒内自动重启它 - 不要手工
ifconfig配VIP或srvctl start vip，这会破坏OCR中资源状态一致性，可能引发后续节点驱逐
多路径问题引发的宕机，本质是底层I/O中断触发的级联故障；修复重点永远在存储路径层，而非上层服务启停逻辑。
