ORA-15281报错磁盘没全上线，Oracle故障远程教你怎么修复

ORA-15281报错磁盘没全上线，Oracle故障远程教你怎么修复

（引用来源：Oracle官方文档《Oracle Automatic Storage Management Administrator's Guide》中关于磁盘组挂载与磁盘管理的章节，以及多位Oracle ACE在技术社区分享的实际故障处理案例）

ORA-15281这个错误，就是你告诉Oracle数据库的存储管理系统（ASM）要去使用一个叫做“磁盘组”的仓库，但是这个仓库里有一些“货架”（也就是物理磁盘）因为各种原因没准备好，或者联系不上了，导致整个仓库没法正常开门营业，ASM为了数据的安全，它很死板，必须要求这个仓库里所有的货架都到位了，它才肯工作，否则就抛出这个15281错误，拒绝挂载磁盘组，下面我就把远程帮别人处理这个问题的常见思路和步骤，用大白话给你讲清楚。

你一看到这个错误,别慌，它的核心原因是磁盘组所需的全部磁盘没有同时在线，就好像一个团队，说好了一起开工，结果有几个人没来，项目经理（ASM实例）就说今天活干不了，我们的任务就是把没来的队员找出来，看看他是迟到了（暂时离线）还是请假了（永久故障），然后想办法让他归队或者找人顶替。

第一步：登录系统，查看现场情况

远程连接上出问题的服务器,首先要用有权限的账户（比如oracle用户）登录到SQL*Plus，连接到ASM实例，不是普通的数据库实例哦，是专门管存储的那个ASM实例，连接上去之后，跑下面这个命令看看热闹：

SQL> SELECT GROUP_NUMBER, NAME, STATE, TOTAL_MB, FREE_MB FROM V$ASM_DISKGROUP;

这条命令是看所有的磁盘组现在是个什么状态,那个报错的磁盘组，它的STATE（状态）很可能是MOUNTED（已挂载）但是有问题，或者是DISMOUNTED（根本没挂载成功），更重要的是，你要看看是不是有的磁盘组压根没出现在这个列表里，那说明它挂载失败了。

第二步：揪出“掉队”的磁盘

我们要看看是哪些具体的磁盘在捣乱,运行这个命令：

SQL> SELECT GROUP_NUMBER, DISK_NUMBER, NAME, PATH, HEADER_STATUS, MODE_STATUS, STATE FROM V$ASM_DISK;

你要像看名单点名一样,仔细看这个查询结果，重点关注以下几列：

• HEADER_STATUS：这个最重要，正常的、已经加入磁盘组的磁盘应该是MEMBER，如果你看到有的磁盘是CANDIDATE（候选，意思是没被用过的新盘），或者更糟的是PROVISIONED（已配置但有问题）、FORMER（前任成员，就是以前属于这个组但现在不是了），又或者是FOREIGN（外来盘，里面有别的ASM的标识），那问题就可能出在这里，那个报错的磁盘组里，如果有磁盘的状态不是MEMBER，或者本该是MEMBER的磁盘却显示MEMBER但STATE（状态）是DISABLED（禁用）之类的，它就是嫌疑犯。
• PATH：这是磁盘的路径，比如/dev/sdb1，记下那些状态不正常磁盘的路径。

第三步：分析“掉队”原因，分情况解决

找到问题磁盘后,就要去操作系统层面查查这个磁盘本身是不是健康的，这需要你有操作系统的权限。

• 磁盘路径错了或者权限不对。 有时候可能是磁盘的设备名变了（比如服务器重启后，/dev/sdb变成了/dev/sdc），或者ASM实例的操作系统用户（通常是oracle）没有读写这个磁盘设备的权限，你可以在操作系统命令行下，用ls -l命令检查磁盘文件的权限，确保oracle用户有权限读写，如果路径变了，你可能需要修改ASM的磁盘发现路径参数（asm_diskstring），或者重新创建磁盘的软链接。

• 磁盘是“候选”盘（CANDIDATE）。 如果磁盘显示为CANDIDATE，说明它物理上存在，但ASM认为它还没加入任何组，这时候你需要手动把它加回磁盘组，命令类似：SQL> ALTER DISKGROUP 你的磁盘组名称 ADD DISK ‘你的磁盘路径’ REBALANCE POWER 11; 这个REBALANCE操作会让ASM重新在磁盘之间平衡数据，可能需要点时间。

• 磁盘物理故障，真的“掉线”了。 如果在操作系统中用fdisk -l或者cat /proc/partitions都根本看不到这块盘了，那很可能是硬件故障、线缆松动、或者存储阵列那边出了问题，这时候你就需要联系系统管理员或者存储管理员了，让他们去检查硬件，如果磁盘确认永久性损坏，并且你的磁盘组有冗余（比如Normal或High冗余），那么你可以强制ASM把这块坏盘从组里踢出去：SQL> ALTER DISKGROUP 你的磁盘组名称 DROP DISK 坏盘的名字 FORCE; 踢掉之后，ASM会根据冗余设置自动用剩下的好盘恢复数据。注意：这一步很危险，只有在确认磁盘无法恢复且组有冗余时才敢用FORCE，否则可能导致数据丢失！

  

• 磁盘状态是“外来盘”（FOREIGN）。 这说明这块盘可能之前属于另一个ASM实例，里面有别人的元数据，如果你想把它用在这个实例的磁盘组里，必须先清掉原来的信息：SQL> ALTER DISKGROUP ALL DISMOUNT; SQL> ALTER SYSTEM SET ASM_DISKSTRING=’你的磁盘路径’; SQL> ALTER DISKGROUP ALL MOUNT; 有时候重新扫描并挂载能解决，如果不行，可能需要用dd命令擦除磁盘头部的信息（极度危险，务必先备份或有专家指导）。

第四步：修复后再次尝试挂载

根据上面的检查结果采取相应措施后,再次尝试挂载那个出问题的磁盘组： SQL> ALTER DISKGROUP 你的磁盘组名称 MOUNT;

如果还不行,回去再看V$ASM_DISK视图，看磁盘状态变了没有，有时候可能需要重启ASM实例（SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP;）来强制重新扫描所有磁盘。

远程处理的心得

远程处理这种问题,最关键的是信息要准，你得像侦探一样，通过客户描述的报错信息，以及让你现场执行的命令反馈，来还原“案发现场”，一定要让操作人员把每条命令的结果都完整地截图发给你，一个字符都不能差，因为路径名、状态词这些细节，差一点，解决方案就完全不同，在进行任何有风险的操作（尤其是DROP DISK FORCE或擦除磁盘头）前，必须反复确认客户是否有可用的备份，并告知风险，如果心里没底，宁可等一等，找更有经验的人商量，也不要盲目执行。

ORA-15281虽然看起来吓人，但大部分情况下，它就是一个“寻人启事”，耐心地把失踪或状态不对的磁盘找出来，根据具体情况安抚好（修复配置）或替换掉（踢出坏盘），问题通常就能解决。