ASM磁盘组不完整导致spfile创建失败：ORA-15040排查与恢复

1. 故障现场：一条spfile命令引发的连环报错

做DBA这行，几乎每个人早晚都会撞上“只是想建一个spfile，结果数据库却连环报错”的场景。上周在某个生产环境的备库切换演练里，我执行一条CREATE SPFILE命令，控制台连续弹出了ORA-17502、ORA-15001、ORA-15040三个错误码。当时我第一反应不是急着翻文档，而是先确认一件事：三个错误一起出现，说明根因大概率只有一个，Oracle只是把同一个底层问题拆成多层报出来了而已。

先交代一下环境：Linux x86_64服务器，Oracle 19c单实例数据库，数据文件、日志文件和部分归档都放在ASM磁盘组+DATA上。业务低峰期做切换演练，为了统一参数管理模式，打算把原本放在文件系统里的pfile改成ASM路径下的spfile。执行的SQL很简单：

CREATE SPFILE='+DATA/ORCL/spfileORCL.ora' FROM PFILE='/u01/app/oracle/product/19.0.0/dbhome_1/dbs/initORCL.ora';

结果SQL*Plus直接把一串红字甩过来：

ORA-17502: ksfd_asm_file_create: 4 failed to create file (DATA) ORA-15001: diskgroup "DATA" does not exist or is not mounted ORA-15040: diskgroup is incomplete

从表面上看，错误码一层套一层，信息量很大，但如果你能把Oracle的报错机制理清楚，这其实是一条非常标准的“ASM磁盘组状态异常”线索链。下面就把三个错误码逐个拆开。

1.1 三个错误码分别代表什么

这三个错误并不是并列的，而是存在明确的调用层级关系。我用一个表格先把它们的位置和含义摆清楚：

从调用链看，数据库实例发现目标文件要落在ASM上，于是向ASM实例发出“请帮我创建文件”的请求，ASM先检查磁盘组是否存在，发现组没挂载，于是抛出ORA-15001；再往下探查磁盘组成员时，发现底层磁盘不齐，于是抛出ORA-15040。ORA-17502是最外层的结果，ORA-15001是中间层判断，ORA-15040才是真正要查的根因方向。

1.2 为什么会同时看到ORA-15001和ORA-15040

很多朋友第一眼看到ORA-15001就去查“磁盘组是否存在”，花了很多时间确认名字没写错，组也存在，但问题依旧。原因就是你只看到了中间层，没往更深一层看。ASM磁盘组处于UNMOUNTED状态时，你去访问它，自然报ORA-15001；而它之所以挂载不起来，是因为磁盘组成员不全，于是底层又带出ORA-15040。

可以这么理解：磁盘组就像一个需要全员到齐才能开张的铺子，ASM启动后发现铺子里少了几个店员，于是拒绝营业。你从外面喊“开门”，它告诉你“没开张”，你追问为什么没开张，它才说“人没齐”。如果只听到第一句就转身去改店名，方向就完全跑偏了。

2. 根因定位：磁盘组为什么“不完整”

既然ORA-15040指向了磁盘组不完整，那就得先搞明白ASM在挂载磁盘组时到底做了什么校验。ASM磁盘组在创建时会记录自己的成员盘信息，这些信息写在每个磁盘的头部，属于元数据的一部分。挂载时，ASM会把当前能发现的磁盘和元数据中记录的成员盘逐一比对，发现缺失就会拒绝挂载并报ORA-15040。

2.1 ORA-15040的触发机制

ASM磁盘组有自己的冗余级别，常见的是EXTERNAL和NORMAL。外部冗余的磁盘组，每一块盘都是独立数据，任何一块丢失都无法挂载，因为数据没有副本。普通冗余的磁盘组，数据在故障组之间有镜像，如果只是少了一块盘，还有可能通过另一份镜像继续服务；但如果少掉的盘刚好让某个故障组的可用盘归零，或者发现盘数量低于元数据记录的安全阈值，ASM同样会报磁盘组不完整。

关键在于：ASM执行挂载动作时，会先做一次全量磁盘发现，再拿发现结果去和磁盘组元数据比对。这个比对过程非常严格，少一块盘都会在alert日志里留下大量“missing disk”之类的记录。所以ORA-15040不是简单的“坏了”，而是“ASM认为这个组的成员盘没有到齐”。

2.2 常见的诱导原因

根据我这些年处理ASM事故的经验，ORA-15040的常见诱因基本集中在下面几种：

• 物理盘掉线。磁盘损坏、光纤线松动、HBA卡故障、阵列侧盘被拔出，这是最直接的原因。
• 多路径软件配置变更。设备在操作系统里的路径名变了，比如从/dev/mapper/asm-disk1变成了/dev/mapper/asm-disk1b，ASM找不到原名。
• asm_diskstring配置不当。ASM实例通过这个参数决定去哪里发现磁盘，如果它只扫描了部分目录，自然漏盘。
• 权限变更。/dev/oracleasm或udev规则调整后，ASM进程没有权限读取某些盘。
• 人为强制卸载。之前执行过ALTER DISKGROUP DATA FORCE DISMOUNT，重新挂载时如果磁盘恢复不到位，也会触发同样的错误。
• 磁盘被意外移出。有人用ALTER DISKGROUP DATA DROP DISK一类的操作处理过盘，但删除还没完成。

2.3 spfile创建为什么会踩到这颗雷

有人会问：我只是建一个spfile，为什么和整组磁盘的完整性有关系？因为spfile要落在+DATA里，就必须在ASM磁盘组上新建一个文件。ASM新建任何文件都要求目标磁盘组处于MOUNTED且健康状态。磁盘组不挂载，或者挂载后成员不全，文件创建请求都会被直接拒绝。

换句话说，spfile只是个导火索，真正的问题是ASM磁盘组本身已经不健康了。哪怕你这一步不去建spfile，接下来做任何涉及ASM的数据库操作，比如创建表空间、写归档日志，迟早都会踩到同样的雷。

3. 排查实战：用几条SQL快速锁定问题

遇到这种报错组合，最忌讳的是直接去重建spfile或者重启ASM实例。重启属于破坏性操作，在没搞清楚磁盘组状态之前，很可能让问题变得更严重。正确的姿势是先用只读的视图把ASM的现状摸清楚。

3.1 先确认你正在操作的是哪个实例

排查第一步不是查磁盘，而是确认自己当前连的是数据库实例还是ASM实例。很多新手在sqlplus / as sysdba之后，没注意ORACLE_SID，以为自己在数据库实例里，其实连到了ASM实例。两个实例的视图和数据完全不同，很容易把人带偏。

echo $ORACLE_SID

如果输出是+ASM，说明你当前处于ASM实例上下文；如果输出是数据库SID，比如ORCL，那就是数据库实例。在我的场景里，创建spfile要通过数据库实例执行，但排查ASM磁盘组状态要去ASM实例执行。后面的查询需要根据当前SID切换环境变量再进SQL*Plus。

3.2 给磁盘组做一个状态体检

进入ASM实例后，最核心的一条SQL就是查看磁盘组状态：

SELECT name, state, type, total_mb, free_mb FROM v$asm_diskgroup;

正常情况下，磁盘组的state字段应该是MOUNTED。如果看到DISMOUNTED，那ORA-15001的由来就很清楚了。我那次的结果是：

NAME STATE TYPE TOTAL_MB FREE_MB DATA DISMOUNTED NORMAL 0 0

所有数字都是0，说明这个组根本没有正常挂载起来。接着查看组里的磁盘成员情况：

SELECT group_number, disk_number, name, state, mode_status, failgroup, path FROM v$asm_disk ORDER BY group_number, disk_number;

结果发现，原本应该有8块盘的DATA组，在ASM的发现列表里只剩6块，group_number为0的候选盘和missing盘占了两个位置。到这里，ORA-15040的根因已经浮出水面：磁盘组成员不齐。

3.3 检查asm_diskstring与磁盘可见性

磁盘组成员不齐，通常是“发现”环节出了问题。ASM通过asm_diskstring参数决定去哪些路径扫描磁盘。在ASM实例里执行：

SHOW PARAMETER asm_diskstring;

我那次配置的是/dev/mapper/asm*，于是去操作系统层面核实这些路径是否存在：

ls -l /dev/mapper/asm*

结果发现，多路径软件在切换演练期间做过一次链路切换，原本的asm-disk5和asm-disk7路径变成了asm-disk5_bak和asm-disk7_bak，名字不匹配，ASM自然发现不了。这就是最典型的“磁盘没坏，但路径变了”的情况。

3.4 判断该恢复还是该重建

在继续操作之前，务必先做一个判断：缺失的盘是临时不可见，还是永久丢失。临时不可见，比如链路切换、路径变更，修复后发现即可；永久丢失，比如盘物理损坏，则需要评估磁盘组冗余级别，走drop disk或重建流程。

从我的现场情况看，两块盘数据应该是完好的，只是多路径软件把设备名改了，属于“临时不可见”。所以最优处理路径是先把路径修正回来，让ASM重新发现磁盘，再挂载磁盘组，最后回去建spfile。

4. 解决方案与操作复现：三条路按优先级走

同样的报错组合，在不同场景下处理方案不同。下面按优先级给出三条可直接抄的路径：先恢复ASM再建spfile是最优解，临时文件系统过渡是保命解，重写参数内容属于兜底操作。

4.1 方案A：修正磁盘路径并重新挂载磁盘组

先处理多路径设备名问题。在操作系统层面把缺失盘路径恢复：

dmsetup rename /dev/mapper/asm-disk5_bak /dev/mapper/asm-disk5 dmsetup rename /dev/mapper/asm-disk7_bak /dev/mapper/asm-disk7 ls -l /dev/mapper/asm*

确认路径恢复后，回到ASM实例，让ASM重新扫描磁盘。先刷新磁盘发现：

ALTER SYSTEM SET asm_diskstring='/dev/mapper/asm*' SCOPE=both;

如果ASM实例已经配置了参数，直接执行：

ALTER DISKGROUP ALL DISMOUNT; ALTER DISKGROUP ALL MOUNT;

不过操作上不建议一次ALL，容易扩大故障面。我习惯先单独处理目标组：

ALTER DISKGROUP DATA MOUNT;

如果这一步仍然报ORA-15040，说明还有盘没被发现，需要继续回到操作系统排查。正常情况下，重新发现全部磁盘后，ALTER DISKGROUP DATA MOUNT会成功。挂载后再查一次视图：

SELECT name, state, total_mb, free_mb FROM v$asm_diskgroup;

看到state为MOUNTED且TOTAL_MB不再为0，磁盘组恢复健康。这时回到数据库实例，重新执行建spfile的命令：

CREATE SPFILE='+DATA/ORCL/spfileORCL.ora' FROM PFILE='/u01/app/oracle/product/19.0.0/dbhome_1/dbs/initORCL.ora';

这次没有报错，spfile顺利生成。用下面的查询来确认当前实例的spfile路径：

SELECT value FROM v$parameter WHERE name='spfile';

4.2 方案B：先落文件系统，保住数据库能启动

有一种更麻烦的场景：磁盘组短时间无法恢复，但数据库不能一直停着，业务等着要起来。这时候可以用文件系统上的spfile先顶着，等ASM磁盘组修复后再迁回ASM。

具体步骤如下。先在数据库实例里把spfile建到文件系统：

CREATE SPFILE='/u01/app/oracle/product/19.0.0/dbhome_1/dbs/spfileORCL.ora' FROM PFILE='/u01/app/oracle/product/19.0.0/dbhome_1/dbs/initORCL.ora';

然后重启数据库：

SHUTDOWN IMMEDIATE; STARTUP;

注意一点：如果pfile里本来包含了指向+DATA的控制文件地址，而磁盘组没恢复，数据库在启动早期阶段就会因为读不到控制文件而失败。这种情况下，临时方案B也不能解决完整问题，只能先修ASM。这恰恰说明ASM磁盘组不健康时，很多操作都会受影响。

等ASM磁盘组恢复后，再把spfile迁回去：

CREATE PFILE='/tmp/pfile_tmp.ora' FROM SPFILE='/u01/app/oracle/product/19.0.0/dbhome_1/dbs/spfileORCL.ora'; CREATE SPFILE='+DATA/ORCL/spfileORCL.ora' FROM PFILE='/tmp/pfile_tmp.ora'; SHUTDOWN IMMEDIATE; STARTUP;

最后一行的STARTUP会自动读取ASM上的spfile，数据库重新以ASM参数文件方式运行。

4.3 方案C：内容校验与最小化重建

如果磁盘组一切正常、spfile还是创建失败，那就要怀疑pfile内容本身有问题。常见的情况是pfile里包含了一些不能写到spfile的劫持性参数，或者文件末尾有非法内容、字符集问题。

先看pfile全文：

cat /u01/app/oracle/product/19.0.0/dbhome_1/dbs/initORCL.ora

重点检查以下几类参数：

• SPFILE参数是否出现在pfile里。pfile里写SPFILE=xxx属于逻辑错误，它会让Oracle在启动时忽略pfile其余内容，无法正常转换。
• CONTROL_FILES里是否引用了还没恢复的ASM磁盘组。
• 参数名写错、数字格式异常等低级问题。

如果排查出内容问题，最稳妥的做法是临时生成一个最小化pfile：

*.db_name='ORCL' *.control_files='+DATA/ORCL/controlfile/current.control'

只保留数据库启动必需的参数，先用这个最小pfile生成spfile到ASM，再通过后续sid初始化参数逐项补齐。生产环境不建议长期使用最小化参数文件，但它能把“文件能不能建出来”和“参数能不能正常启动”两件事彻底分开，定位问题非常有效。

5. 避坑指南：spfile与ASM相关的常见误区和经验

这一部分是把这些年遇到过的高频问题总结成一张速查表，配合几条实操心得。很多错误不是第一次才出现的，而是同一类问题换个马甲反复出现。

5.1 spfile、pfile与init.ora的底层差别

简单梳理一下三者的关系。pfile是纯文本参数文件，可以用vi直接改；spfile是二进制格式的参数文件，数据库运行时修改参数会自动写回spfile。init.ora只是pfile的默认命名习惯，比如initORCL.ora。

创建spfile时如果报“参数错误”或“文件无法创建”，先分清到底是在转换阶段失败还是在写ASM阶段失败。转换阶段失败通常是参数格式问题，写ASM阶段失败通常是我们前面讲的磁盘组问题。从错误码的层级能判断：ORA-17502出现，说明已经到了“写ASM文件”这一步，不是转换阶段。

5.2 单实例与集群环境下的差异

单实例下，ASM和数据库实例大多在同一台机器，排查相对简单。RAC环境下问题会复杂很多：同一个磁盘组必须在所有节点都处于MOUNTED状态，如果某个节点因心跳、网络分区或磁盘发现不完整而没有挂载，在那个节点上执行涉及ASM的操作就会得到ORA-15001。

另外RAC环境里spfile通常要放在所有实例都能访问到的共享存储上，也就是ASM。如果只有一个节点能正常挂载磁盘组，其他节点都报ORA-15001，优先检查集群状态和每个节点的磁盘发现配置，而不要反复在单节点上重试。

下面是一张经验速查表：

5.3 我踩过的几个坑

第一个坑是磁盘组名字大小写。ASM的磁盘组名在内部以大写字存储，平时写+data多半没问题，但在某些脚本化操作里，小写会触发ORA-15001。排查时先把名字完全对齐大写，再谈别的。

第二个坑是ASMCMD里没有手动创建别名目录。第一次建spfile到+DATA/ORCL/时，如果ORCL目录不存在，ASM可能不会自动创建，导致文件创建失败。稳妥做法是先用asmcmd建目录：

asmcmd mkdir +DATA/ORCL

第三个坑是没备份就直接重建。spfile一旦被覆盖，原来的参数配置就找不回来了。执行创建命令前，永远先留一份pfile快照：

CREATE PFILE='/tmp/pfile_backup_before_spfile.ora' FROM SPFILE='/u01/app/oracle/product/19.0.0/dbhome_1/dbs/spfileORCL.ora';

如果原本没有spfile，也要先备份现有的pfile。

第四个坑是忽略alert日志。SQL*Plus窗口里的报错只是一部分，ASM实例的alert日志会记录mount过程中每一个缺失磁盘的详细路径和原因。出问题时，同时打开数据库实例和ASM实例两份alert日志对比，很多看似玄学的现象都能找到确凿记录。

6. 排障手记与个人体会

把这次排障完整复盘下来，我最深的体会是：处理ORA错误组合时，克制住“立刻执行重建或重启”的冲动比什么都重要。三个错误码一起出现，看着吓人，只要顺着错误层级往上剥，先看最外层动作，再看ASM判断，最后揪住磁盘组成员完整性这个根子，问题范围就能从“整库瘫痪”缩小到“某几块盘的发现路径异常”。

操作顺序上也有一条铁规矩：先只读排查，后修复，再验证，最后才是重建参数文件。我当时就是先查了v$asm_diskgroup和v$asm_disk，确认少盘后才动多路径设备名，整个过程没有让生产业务再受一点损伤。

最后再分享一个小技巧：在服务器上预先把这几条排查SQL保存成一个脚本，命名为asm_health.sql，遇到ASM相关报错直接执行。ASM磁盘组本身就是整个数据库的底盘，底盘出问题的时候，往往也是数据库最慌的时候，提前备好这些“定心丸”，能省掉一半以上的焦虑时间。