ASM实例报ORA-15251错误只能限制挂载，远程修复思路分享

ASM实例报出ORA-15251错误，并且只能以限制模式（RESTRICTED）挂载磁盘组，这是一个让很多Oracle数据库管理员头疼的问题，这个错误的核心意思是，ASM实例在尝试正常挂载磁盘组时，发现了一个或多个磁盘的路径（也就是操作系统层面识别磁盘的地址）发生了改变，但ASM内部记录的原有的路径信息仍然存在，两者对不上号，ASM出于保护数据安全的目的，拒绝完成挂载，它只允许你以限制模式挂载，这个模式下只有ASM实例本身能连接，普通的数据库实例是无法连接上来访问数据的，所以数据库自然也就无法启动。

这个问题的根源通常发生在服务器硬件变更之后,比如更换了HBA卡（连接服务器和存储的硬件）、重新配置了多路径软件、或者存储阵列自身进行了端口调整，这些操作都可能使得操作系统看到的磁盘设备名（在Linux下可能是从 /dev/mapper/mpatha 变成了 /dev/mapper/mpathb）发生改变，ASM在设计上强烈依赖于稳定的磁盘路径标识，一旦发生变化，就会引发ORA-15251。

当遇到这种情况时,如果能够物理上接触到服务器，解决起来相对直观，但挑战在于如何进行远程修复，因为你可能无法直接控制服务器的控制台，操作存在风险，以下是一个基于多位有经验DBA分享的思路和操作步骤，核心目标是更新ASM的磁盘路径信息，使其与操作系统当前的实际路径保持一致。

第一步：确认问题并收集信息

你需要连接到服务器的操作系统,并获取root用户或同等权限，连接到只能以限制模式挂载的ASM实例。

1. 检查磁盘组状态：在ASM实例中执行 SELECT GROUP_NUMBER, NAME, STATE FROM V$ASM_DISKGROUP;，你会看到有问题的磁盘组状态应该是 RESTRICTED。
2. 查看问题磁盘：执行 SELECT GROUP_NUMBER, DISK_NUMBER, MOUNT_STATUS, HEADER_STATUS, PATH FROM V$ASM_DISK ORDER BY PATH;，仔细查看输出，你会发现一些磁盘的 HEADER_STATUS 可能是 FORMER（表示ASM认为这个路径的磁盘已经不存在了），而它们对应的新路径可能根本就没有出现在列表中，或者状态异常，记下所有状态异常的磁盘的 DISK_NUMBER 和旧的 PATH。

第二步：在操作系统层面确认新路径

你需要在操作系统层面找到这些“失踪”的磁盘现在到底在哪里。

1. 使用多路径命令：运行像 multipath -ll 这样的命令（具体命令取决于你的多路径软件），它会列出所有由多路径管理的大容量磁盘，你会看到每个磁盘有一个唯一的WWID（全球标识符），以及它当前对应的设备映射器路径（/dev/mapper/3600abc123）。
2. 交叉比对：将 multipath -ll 的输出与之前ASM中记录的旧路径进行比对，目标是找到那些WWID相同（这代表了同一块物理磁盘），但设备路径已经改变的磁盘，记下每个问题磁盘的新路径。

第三步：谨慎地进行修复操作

这是最关键也最危险的一步,务必确保你识别的新旧路径对应关系是100%正确的，整个修复过程需要在ASM实例中完成。

1. 开始修复：确保有问题的磁盘组已经以限制模式挂载。
2. 取消挂载磁盘组：在尝试修改磁盘路径前，可能需要先取消挂载磁盘组，执行 ALTER DISKGROUP <磁盘组名> DISMOUNT;。
3. 使用FORCE选项重新挂载：为了允许ASM进行磁盘路径的更新，你需要使用强制选项来尝试挂载：ALTER DISKGROUP <磁盘组名> MOUNT FORCE;，这个命令会强制ASM扫描所有可能的磁盘路径，并尝试与磁盘头中的信息进行匹配，有时，仅仅这一步就能自动解决问题。
4. 如果强制挂载失败，则手动更新路径：MOUNT FORCE 之后问题依旧，就需要手动干预了，使用ASM的 ALTER DISKGROUP ... ONLINE DISK 命令来指定新的路径，命令格式通常类似于： ALTER DISKGROUP <磁盘组名> ONLINE DISK '<新路径>' POWER 1 WAIT; 你需要将 <新路径> 替换为在第二步中找到的正确的新操作系统设备路径。POWER 1 表示以较低的并行度进行操作，WAIT 表示等待操作完成，你需要为每一个路径发生改变的磁盘执行这个命令。
5. 验证修复结果：在执行完在线操作后，再次查询 V$ASM_DISK 视图，确认之前状态为 FORMER 的磁盘现在 HEADER_STATUS 是否已经变为 MEMBER，PATH 已经更新为新的路径，检查磁盘组状态是否从 RESTRICTED 变为了 MOUNTED。

第四步：测试并恢复正常

1. 取消限制模式：确认磁盘组所有磁盘状态正常后，取消其限制模式，执行 ALTER DISKGROUP <磁盘组名> DISMOUNT; 卸载磁盘组，然后再执行 ALTER DISKGROUP <磁盘组名> MOUNT; 进行正常挂载。
2. 启动数据库：尝试启动依赖于此ASM磁盘组的数据库实例，如果数据库能够正常启动并打开，说明修复成功。
3. 备份ASM元数据：修复成功后，强烈建议立即对ASM的元数据进行备份，可以使用 md_backup 命令来备份磁盘组的元数据，这在未来遇到类似问题时将是一个救命稻草。

远程修复的重要注意事项

• 备份意识：在任何实质性操作之前，如果条件允许，应尝试备份当前的ASM元数据，虽然数据可能因磁盘组未挂载而无法访问，但元数据备份有时在限制模式下也是可行的。
• 操作记录：详细记录下你每一步的操作命令和系统的输出结果，如果操作失误，这些记录是回滚或寻求进一步帮助的关键。
• 风险意识：远程操作无法直接控制硬件，存在一定风险，如果对操作没有十足把握，最好能协调机房人员或更资深的专家在场（哪怕是远程指导）的情况下进行。
• 预防优于治疗：为了避免此类问题，应规范服务器硬件和存储的变更流程，在变更前，确保已记录下所有ASM磁盘的WWID和路径对应关系，考虑使用ASM Flex Diskgroup或者更高的兼容性属性，它们能提供更好的可用性和可恢复性。

远程修复ORA-15251错误是一个需要耐心和细心的过程，核心在于准确地识别出磁盘路径的变更，并安全地引导ASM实例更新其内部记录，通过上述系统性的思路和步骤，可以在很大程度上远程解决这个棘手的问题。