Oracle RAC集群的ASM磁盘组状态显示offline或online，本质上涉及两个不同层级的对象：一是磁盘组本身的挂载状态，二是组成磁盘组的底层磁盘可用状态。很多DBA在巡检时看到crsctl stat res -t输出里某个ASM相关资源显示offline，第一时间会尝试用srvctl start asm或者手动mount磁盘组，结果发现有时能恢复，有时却触发了更严重的集群问题。造成这种差异的原因在于，offline这个描述可能来自ASM实例内部的磁盘状态，也可能来自Cluster Ready Services对资源健康度的判定，还可能是OCR或Voting File所在磁盘组脱离集群共识机制后的表现。要让集群稳定回到online，首先必须弄清楚是哪一层出现了离线，而不是简单地把所有问题都归为ASM磁盘组坏了。
在Windows Server环境中运行Oracle RAC时，还需要额外关注操作系统层面的服务依赖关系。例如Oracle Cluster Volume Service、Oracle Object Service以及ASM实例对应的Windows服务，如果它们的启动顺序发生错乱，或者服务账户权限被域策略修改，同样会导致ASM磁盘组在集群启动阶段无法正常挂载，表现为online后又瞬间变成offline。注册表路径HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\OCR中保存着OCR磁盘组的定位信息，一旦这个路径下的键值被错误清理或磁盘签名变化，Windows底层可能先于Oracle软件感知到设备丢失，进而让整个OCR磁盘组进入offline状态。因此排查思路必须从集群层、实例层、存储层三个维度同时展开。
1. 区分磁盘组状态与磁盘状态的offline/online
ASM磁盘组层面的状态信息可以通过v$asm_diskgroup视图查询，其STATE字段的典型取值包括CONNECTED、MOUNTED、DISMOUNTED，个别平台还会出现BROKEN或者UNKNOWN。严格来说，v$asm_diskgroup里并不会直接出现offline或者online这样的字符串，很多初学者看到的offline其实来自v$asm_disk视图的STATE字段，该字段针对ASM磁盘会显示ONLINE、OFFLINE、DROPPING、FORCING等值。所以当有人告诉你磁盘组offline了，你应该立即确认他指的是磁盘组被dismount，还是其中的某块磁盘被ASM标记为offline，二者在恢复策略上完全不同。
在RAC环境中，除了ASM内部视图，Cluster Ready Services也会维护一套资源状态。OCR和Voting File所在的磁盘组通常被注册为ora.asm、ora.
Windows环境下可以用命令C:\app\oracle\product\19.0.0\dbhome_1\bin\crsctl.bat check css和C:\app\oracle\product\19.0.0\dbhome_1\bin\crsctl.bat check crs来快速确认集群基础服务是否健康。如果CSSd状态正常但CRS资源异常，再进一步排查ASM实例的alert日志。日志路径通常位于C:\app\oracle\diag\asm\+asm\ASM1\trace\alert_ASM1.log，其中ASM1对应节点1的实例名，具体目录结构可能随版本变化。查看日志时重点关注是否有ORA-15063、ORA-15040、ORA-29702等错误码，这些错误可以辅助判断是磁盘组被手动dismount，还是底层I/O超时导致ASM主动将其卸载。
2. 导致磁盘组offline的常见原因与定位方法
最常见的原因是集群节点间的私有网络瞬断。Oracle RAC中每个节点的ASM实例都依赖CSSd维护的成员资格，一旦心跳超时，CSSd会触发节点重启或驱逐机制。被驱逐节点的ASM实例异常终止后，其管理下的磁盘组资源自然变成offline。判断这类故障可以查看被驱逐节点的事件日志，Windows事件查看器中Oraclevsswriter、OraFenceService等来源的记录，也可以查看CSSd的日志文件，通常位于C:\app\oracle\diag\crs\节点名\crs\trace\ocssd.trc。如果日志里出现reboot advisory或者member kill字样，基本可以确认是心跳问题导致的级联离线。
第二类常见原因是存储链路抖动或多路径软件切换失败。Windows Server通常使用MPIO或厂商多路径软件来管理共享磁盘，如果某条FC或iSCSI路径闪断后，多路径软件没有及时完成故障切换，ASM磁盘会出现瞬时I/O错误。ASM默认的disk_repair_time参数决定了磁盘被offline后多长时间内允许自动重新上线，如果超过该时间窗口，磁盘会被标记为强制offline，之后需要手动执行alter diskgroup ... online disk操作。在Windows上检查多路径状态可以使用mpclaim.exe -s -d命令，该命令输出的路径状态中如果存在failed或者degraded，说明存储层确实出现了问题。
还有一类比较隐蔽的原因是OCR或Voting File所在磁盘组的权限被破坏。Windows下Oracle使用操作系统级别的安全描述符来控制对共享磁盘的访问，如果域管理员在磁盘管理器中重新初始化了磁盘，或者修改了磁盘的签名，ASM会认为该磁盘已经不是原来那台设备。此时注册表HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\OCR下的键值可能还指向旧的磁盘路径，但底层磁盘已经无法被识别。建议先用diskpart工具执行list disk确认磁盘编号和签名是否与安装时一致，再检查Windows注册表中OCR相关键值是否完整。如果规模较大的集群还配置了OCR镜像，可以尝试使用ocrconfig -showbackup查看最近的OCR备份信息。
3. 恢复offline磁盘组的操作流程与注意事项
恢复操作必须遵循先确认集群状态、再恢复存储、最后挂载磁盘组的顺序，切忌上来就执行强制启动。首先在所有存活节点上运行crsctl check cluster -all，确认哪些节点还正常参与集群。如果存在节点被驱逐，先解决心跳网络问题，等待该节点自动或手动加入集群。对于仅剩一个节点的环境，不要贸然执行crsctl start crs，因为缺少必要的对等节点时可能无法形成法定人数，导致OCR磁盘组永远无法挂载。此时可以检查voting disk的配置，使用命令crsctl query css votedisk，确认投票盘是否都存在于共享存储且路径可见。
如果确认集群基础服务正常，但某个ASM磁盘组仍处于dismounted状态，可以通过sqlplus以sysasm身份连接到ASM实例，执行查询select name,state,type from v$asm_diskgroup;检查状态。若显示DISMOUNTED，可以执行alter diskgroup DATA mount;将其挂载回来。注意如果该磁盘组包含OCR或Voting File，挂载前必须确保当前节点上的CSSd和GPnP服务已经正常启动，否则可能报错ORA-15077或ORA-15130。对于普通数据磁盘组，mount操作通常是安全的；但对于OCR磁盘组，建议使用crsctl start crs命令由集群整体拉起，而不是手动在某个节点单独挂载，以免破坏集群一致性。
SQL> select name, state, type, total_mb, free_mb from v$asm_diskgroup; SQL> select name, path, state, mount_status from v$asm_disk; SQL> alter diskgroup DATA mount;
如果ASM磁盘组中被标记为offline的是某一块具体磁盘，需要先确认该磁盘的物理状态是否已经恢复。可以在ASM实例中查询select name,state,header_status from v$asm_disk where group_number=1;如果state为OFFLINE且header_status为UNKNOWN，说明ASM已经无法正常读取磁盘元数据。这时可以尝试执行alter diskgroup DATA online disk 'DISK1';其中DISK1是磁盘的ASM名称。执行后再次查看v$asm_disk.state，如果变为ONLINE且group_number恢复正常，说明磁盘重新加入成功，ASM会自动开始同步数据。如果online disk命令报错ORA-15032或ORA-15033，表明磁盘上的ASM元数据已损坏，需要考虑从备份恢复或者重建磁盘组。
对于Windows平台，还有一个容易忽略的步骤是检查Oracle相关的Windows服务是否处于自动运行状态。打开services.msc，确认OracleClusterVolumeService、Oracle OHAS Service、Oracle ASM实例服务以及对应磁盘组的Oracle ASM Disk Group服务都已经启动。如果某个磁盘组的服务被手动停止，即使ASM实例正常，该磁盘组也会显示为offline。可以通过命令C:\app\oracle\product\19.0.0\dbhome_1\bin\srvctl.bat status asm -detail查看ASM资源的详细状态，再用srvctl start diskgroup -g DATA -n node1重新启动指定节点上的磁盘组资源。整个恢复过程中要持续观察alert日志，确认所有重平衡操作顺利完成，避免在数据同步未结束时再次进行节点切换。
Oracle RACASM磁盘组磁盘组状态修改时间：2026-09-19 16:29:33