ASM磁盘组报ORA-15276，投票文件冲突导致故障远程帮忙修复

开始）

这是一个记录远程处理一套Oracle数据库因ASM磁盘组故障导致无法启动的真实案例，当时，数据库服务器在重启后，ASM实例能够启动，但数据库实例在启动到mount阶段时，遭遇了严重的错误，提示ORA-15032、ORA-15017，最终的核心错误是ORA-15276：无法为磁盘组“DATA”分配服务器。

用户那边非常着急，因为业务已经完全中断，我通过远程连接工具登录到服务器后，首先查看了数据库的告警日志，告警日志里密密麻麻地记录着错误信息，核心内容就是ASM无法识别到磁盘组“DATA”中的磁盘，或者说识别到的磁盘状态异常，导致数据库实例在尝试挂载这个磁盘组时失败，进而报出ORA-15276错误。

我切换到grid用户（ASM的管理员用户），进入ASM实例，使用命令asmcmd lsdg查看磁盘组状态，发现名为“DATA”的磁盘组状态确实是MOUNTED，这看起来有点奇怪，因为数据库实例说挂载不了，但ASM实例显示它是已挂载的，当我使用asmcmd lsdsk命令查看磁盘状态时，问题开始显现，我发现属于“DATA”磁盘组的几块磁盘中，有一块或多块磁盘的路径（path）状态异常，显示为CANDIDATE（候选）或者PROVISIONED，而不是正常的MEMBER（成员）状态，这意味着ASM实例虽然认到了这些物理磁盘，但没有把它们当作有效的成员纳入到“DATA”磁盘组中。

为什么会这样？通常原因有几个：磁盘路径本身有问题（比如多路径配置混乱）、磁盘头信息损坏，或者就是我们这次遇到的特殊情况——投票文件（Voting File）冲突，Oracle集群需要投票文件来管理集群成员和进行脑裂仲裁，在标准配置中，投票文件会存放在各个磁盘组上，如果底层存储发生了变更，例如磁盘被重新映射、LUN ID改变，或者之前做过不完全的磁盘组重建操作，就可能导致ASM在扫描磁盘时，在不同的路径上发现了“看起来”属于同一个磁盘组的、但内容不一致的投票文件信息，这就产生了冲突，ASM出于保护机制，不敢轻易将磁盘加入组内,从而导致了上述的磁盘状态异常。

为了确认是否是投票文件的问题，我使用了asmcmd的一个关键命令：asmcmd lsof，这个命令可以列出ASM磁盘组上存放的所有文件，包括数据文件、控制文件、在线日志文件，以及非常重要的投票文件，执行命令后，果然发现了异常，在系统原本的“DATA”磁盘组名下，应该存在的投票文件条目不见了，或者状态可疑，在lsdsk命令显示的某个状态为CANDIDATE的磁盘上，asmcmd的lsdsk -p命令（带详细参数）显示该磁盘的头部包含有旧的、可能已经失效的磁盘组信息和投票文件痕迹。

情况基本明朗了：由于某种原因（可能是存储层面的意外操作），导致ASM认为当前磁盘组中的投票文件出现了不一致或冲突，它无法确定哪个才是“权威”的,因此拒绝正常挂载磁盘组供数据库使用。

修复的思路是：我们必须确保所有节点的ASM实例都已关闭，避免在操作过程中有节点尝试访问磁盘，我们需要清理掉有冲突的、陈旧的磁盘头信息，让ASM能够“干净”地重新识别磁盘，再以强制方式重新挂载磁盘组,恢复其上的文件。

具体操作步骤如下：

1. 关闭所有实例：我让用户确认并关闭了数据库实例，我在所有集群节点上，以grid用户执行crsctl stop has命令，停止整个高可用服务栈，这会同时停止ASM实例,确保所有节点的ASM实例都已完全停止是非常重要的前提。

   

2. 清理磁盘头信息：这一步是关键且需要非常小心，我们使用Oracle提供的磁盘清理工具dd，必须精准地找到那块（或那几块）状态异常、头部有残留信息的磁盘设备路径，确认无误后，使用命令dd if=/dev/zero of=/dev/磁盘设备名 bs=1M count=100来覆盖清除磁盘头部的一小部分数据（通常是前100MB），这足以破坏掉旧的ASM元数据和投票文件信息，但不会影响磁盘大部分区域的数据。注意：这个操作具有破坏性，必须百分百确认磁盘路径正确，否则会导致数据永久丢失。

3. 重新扫描磁盘：清理完成后，在一些系统中，可能需要通知操作系统重新扫描SCSI总线以识别磁盘变化，命令如rescan-scsi-bus.sh（如果系统有安装）或通过echo命令到特定的sysfs接口，这一步是为了确保系统看到的是清理后的“干净”磁盘。

4. 强制挂载磁盘组：再次以grid用户启动ASM实例（可以通过crsctl start has启动整个集群栈，或者先单独启动ASM实例），启动后，再次使用asmcmd lsdsk查看，之前状态为CANDIDATE的磁盘现在应该变成了PROVISIONED或CANDIDATE（但已经是干净的），尝试正常挂载磁盘组可能仍然失败，我们需要使用强制选项，在ASM实例中，执行SQL命令：ALTER DISKGROUP DATA MOUNT FORCE;，这个FORCE关键字告诉ASM，忽略一些不一致的警告，基于现有的、有效的磁盘成员信息强行挂载磁盘组。

5. 验证恢复结果：强制挂载命令执行后，再次使用asmcmd lsdg和asmcmd lsdsk确认“DATA”磁盘组的状态为MOUNTED，所有预期磁盘的状态为MEMBER，切换到oracle用户，尝试启动数据库实例，当输入startup命令后，这次数据库顺利地经过了nomount阶段，在mount阶段成功识别并挂载了ASM磁盘组上的控制文件，最终成功打开数据库，立即检查告警日志，之前刷屏的ORA-15276等错误信息消失了，取而代之的是正常的数据库启动和恢复记录,随后进行的简单查询测试也确认了业务数据可以正常访问。

至此，这次由投票文件冲突引发的ORA-15276故障被成功修复，整个远程处理过程耗时约一个多小时，核心在于精准定位到冲突根源（陈旧的投票文件信息），并通过谨慎的清理和强制挂载操作恢复了磁盘组，事后，我们建议用户检查近期的存储配置变更记录，并加强变更管理流程，以避免类似问题再次发生。 结束）