当前位置：首页 > 问答 > 正文

ORA-15411报错磁盘组故障修复，远程处理时发现磁盘数量不一致问题

瞿欣合
问答
2025-12-27 08:49:29
4

ORA-15411报错磁盘组故障修复，远程处理时发现磁盘数量不一致问题

ORA-15411报错的初步认识

当甲骨文（Oracle）数据库管理员在使用ASM（自动存储管理）技术管理数据库存储时，可能会遇到一个名为ORA-15411的错误，这个错误的核心信息通常是“磁盘组字符串正在被另一操作占用”（Oracle Support Document ID 1381797.1），就是系统检测到您正试图对某个磁盘组（比如DATA磁盘组）执行一个管理操作（挂载MOUNT、重新平衡REBALANCE、或者添加/删除磁盘），但这个磁盘组当前“正忙”，有另一个操作还在进行中，导致新的操作无法立即执行。

在本地数据中心环境中,DBA可以相对直接地登录到服务器上，检查ASM实例的告警日志，运行一些诊断命令，来查看究竟是什么操作卡住了，当这个问题发生在需要通过远程连接进行维护的服务器上时，排查过程会变得复杂，一个尤其令人困惑的情况是，在尝试解决ORA-15411的过程中，进一步发现ASM检测到的磁盘数量与操作系统层面实际可见的磁盘数量不一致，这就像您明明知道仓库里有10个货架（物理磁盘），但仓库管理系统（ASM）却只识别出8个，另外两个要么“失踪”，要么状态异常，这直接阻碍了任何修复操作的进行。

远程处理时发现磁盘数量不一致的常见场景

ORA-15411报错磁盘组故障修复，远程处理时发现磁盘数量不一致问题

在远程处理ORA-15411问题时，磁盘数量不一致的发现往往不是孤立的，它通常是更深层次问题的表象，根据多位DBA在Oracle社区（如Oracle Forums, My Oracle Support Community）分享的经验，常见场景包括：

多路径软件配置问题： 这是最普遍的原因之一，为了提供高可用性，服务器通常会通过多条物理路径连接到存储设备，这需要多路径软件（如Linux下的DM-Multipath）来管理，如果多路径软件配置不当、服务未正常启动、或者配置变更后未重新扫描，就会导致操作系统层面看到的是一条条“虚路径”（多路径聚合后的设备），而ASM层面可能看到了多条“实路径”（单个物理路径），或者相反，结果就是两边看到的“磁盘”数量对不上（参考自多位DBA在社区中关于 multipath.conf 配置错误的讨论）。
存储网络（如SAN）瞬时中断： 在远程维护期间，网络稳定性是关键，如果服务器与存储阵列之间的光纤通道（FC）或iSCSI连接发生短暂的、可能未被立即察觉的中断，可能导致部分磁盘路径（LUN）从操作系统中“丢失”（offline），ASM可能还保留着这些磁盘的“记忆”，但其状态已变为“无法访问”，当您检查时，就会看到数量不一致，这种问题在虚拟化环境或云环境中也可能发生。
操作系统设备映射持久化问题： 在Linux系统中，/dev/下的设备名（如sdb, sdc）可能在重启后发生变化，虽然最佳实践是使用WWID或通过UDEV规则绑定静态设备名（如/dev/mapper/下的名称）供ASM使用，但如果配置不牢固，重启后ASM使用的磁盘设备名可能指向了错误的物理磁盘，导致部分磁盘无法正确识别，从而引发数量差异（依据Oracle官方安装文档中关于ASM磁盘发现的建议）。
先前未完成的ASM操作遗留的影响： 最初的ORA-15411报错，可能就是由一个诸如添加或删除磁盘的操作引发的，如果这个操作在过程中被意外中断（如网络断连、系统重启），可能会留下一个“烂摊子”，ASM内部可能仍然认为某个磁盘处于“正在被添加”或“正在被删除”的过渡状态，这使得该磁盘既不属于完整的磁盘组成员，又没有被完全释放，造成数量统计上的混淆和后续操作的锁定状态（Oracle Support Document ID 1381797.1 中提及了操作挂起的情况）。

远程诊断与修复步骤思路

面对这种复合型问题,远程处理需要清晰的思路和谨慎的操作，避免使情况恶化。

详细收集信息，避免盲目操作： 这是远程修复的第一步，也是最重要的一步，因为无法直接接触控制台，信息就是一切，需要同时从操作系统和ASM实例两个层面收集数据。
- 操作系统层面： 使用命令（如 lsblk, fdisk -l, multipath -ll）全面列出所有块设备和多路径设备，仔细核对磁盘的大小、WWID等信息，确认物理磁盘是否真的在线且可读。
- ASM实例层面： 连接到ASM实例，查询相关视图。SELECT GROUP_NUMBER, DISK_NUMBER, PATH, HEADER_STATUS, MODE_STATUS, STATE FROM V$ASM_DISK; 这个命令能显示ASM认识的所有磁盘，无论其是否属于某个磁盘组，重点关注 HEADER_STATUS 和 STATE 字段，如果磁盘状态是“MISSING”、“FORMER”（前任成员）或“PROVISIONED”（已配置但未加入），都解释了数量不一致的原因，一定要检查ASM的告警日志（alert_+ASM.log），寻找在ORA-15411错误发生前后是否有关于磁盘路径失败、超时或状态变化的记录（方法参考Oracle Database Administrator's Guide）。
解决磁盘可见性问题： 基于收集到的信息，先着手解决磁盘数量不一致的根本。
- 如果是多路径问题： 检查多路径服务状态，重新加载配置，并重新扫描SCSI总线以重新发现磁盘，确保ASM使用的磁盘路径是稳定的多路径虚拟设备，而非单个物理路径。
- 如果是存储连接问题： 与存储管理员协作，远程检查存储阵列上对应LUN的映射和状态，确认所有路径都健康且对主机可见，可能需要在线重新扫描光纤通道HBA卡或iSCSI会话。
- 清理ASM磁盘头： 如果确认某块磁盘在物理上已彻底损坏或不再使用，但其磁盘头信息仍被ASM记为“候选盘”或处于异常状态，可以在万不得已、确保数据安全的前提下，使用Oracle提供的 dd 命令清除磁盘头信息，使其对ASM彻底“不可见”，但这步操作风险极高，必须百分百确认该磁盘已不包含任何有效数据（警告：此操作需极端谨慎，参考Oracle Support Document ID 602620.1）。
解除ASM操作锁定： 在确保底层磁盘状态稳定且一致后，再回头处理最初的ORA-15411错误，如果确认是某个挂起的REBALANCE（重新平衡）操作导致的锁定，可以尝试使用 ALTER DISKGROUP ... REBALANCE POWER 0; 命令来优雅地停止当前的重平衡操作，然后再以合适的功率重启它，在某些极端情况下，如果ASM实例的内部状态确实卡死，可能需要重启ASM实例来清除所有锁，但重启ASM意味着其管理的所有数据库实例都会暂时中断，这必须在计划维护窗口内进行，并做好充分预案（Oracle Support Document ID 1381797.1 提供了处理挂起操作的方法）。