asm磁盘组掉线且无法mount是因磁盘头或asm元数据损坏导致的结构性故障，需通过只读镜像、kfed分析、元数据修复及手动重组diskgroup来恢复，强行mount或force参数无效且危险。
asm 磁盘组掉线后，asm 实例无法 mount，oracle 数据库自然无法启动 —— 这不是配置错误，而是底层元数据损坏导致的结构性故障。强行重启或反复执行 alter diskgroup ... mount 通常无效，必须从元数据层面切入。
为什么 ALTER DISKGROUP ... MOUNT 总是报 ORA-15032 / ORA-15040 / ORA-15042？
这些错误本质是 ASM 内核在读取磁盘头（disk header）和 AU 0 区域时校验失败。常见原因包括：
- 磁盘头中关键字段（如 disk number、group number、failgroup name）被覆盖或错位
- ASM 元数据区（AU 1–4）中的 disk directory 或 template directory 损坏
- 磁盘顺序错乱（比如多盘系统中物理插槽变更，但 udev 规则未同步，导致 /dev/sdb 实际映射到原 /dev/sdc 的盘）
- 磁盘被误格式化、分区表写入、或 LVM 层叠干扰（尤其在虚拟化环境中）
注意：一旦看到 ORA-15042（"disk string is missing from the diskgroup"），说明 ASM 已无法识别某块磁盘的身份，不能靠 FORCE 参数绕过 —— 强行加 FORCE 可能引发元数据进一步错乱。
如何安全提取并验证 ASM 元数据？
跳过 ASM 实例，直接从裸设备读取原始扇区是唯一可靠起点。操作前务必做只读镜像：
- 使用 dd if=/dev/sdX of=/backup/sdX.img bs=1M conv=noerror,sync 对每块 ASM 磁盘完整镜像
- 镜像完成后，用 kfed read /backup/sdX.img 查看磁盘头结构
- 重点检查输出中 kfbh.type 是否为 1（KFBTYP_DISKHEAD）、au 字段是否非零、grpnum 和 dsknum 是否与预期一致
- 若某盘 kfed read 报错或 grpnum = 0，该盘磁盘头已损毁，需用其他盘的元数据推算修复，或依赖备份的 asmcmd md_backup 文件
- 不要依赖 asmcmd lsdg 或 v$asm_disk —— 它们依赖已运行的 ASM 实例，此时不可信
手动重组 diskgroup 前必须确认的三件事
重组不是“重试挂载”，而是重建内存中的 diskgroup 结构。以下条件缺一不可：
- 所有磁盘镜像已就位，且至少一块磁盘的 kfed read 能正确输出 grpnum 和有效 dsknum
- 已通过 kfed read 或 strings -a /backup/sdX.img | grep -i "ORCLDATA"（替换为你的 DG 名）交叉比对各盘的 diskgroup 名称一致性
- 确认磁盘冗余类型：外部冗余（external）可容忍单盘丢失；普通冗余（normal）需至少两块盘完好且 failgroup 分布正确；高冗余（high）要求三块不同 failgroup 的盘 —— 若不满足最低盘数，CREATE DISKGROUP 会失败，不要硬试
用 kfed + asmcmd 创建新 diskgroup 并导入数据文件
当元数据确认可恢复，且盘数满足冗余要求时，可走最小干预路径：
- 用 kfed merge 修复单个磁盘头（仅限轻微损坏，如 dsknum 错位），例如：kfed merge /backup/sdX.img text=/tmp/diskhead.txt，其中 text 文件需手工修正 dsknum 字段
- 启动一个干净的 ASM 实例（无其他 diskgroup），执行：CREATE DISKGROUP ORCLDATA NORMAL REDUNDANCY FAILGROUP FG1 DISK '/backup/sdX.img' FAILGROUP FG2 DISK '/backup/sdY.img';
- 成功后，asmcmd cp 无法使用（因源盘非 live 设备），改用 dd 按 AU 提取数据文件：定位数据文件起始 AU（通过解析 AU 1 的 file directory），再用 dd if=/backup/sdX.img of=/recovered/data01.dbf bs=1048576 skip=N count=M
- 提取出的 .dbf 文件需用 rman target / + RESTORE DATAFILE 或直接拷贝到新库的 DB_CREATE_FILE_DEST 下并 RECOVER DATAFILE
关键提醒：Oracle 11g 的 ASM 不支持跨版本元数据兼容。若原环境是 11.2.0.4，但你用 11.2.0.1 的 kfed 解析，可能读出错误的 AU 大小或条带信息 —— 务必匹配主版本号。
