ora-15335表明asm元数据损坏，需先排除asm_diskstring配置错误等低级问题，再通过kfod、kfed、amdu诊断并抢救数据，最后验证文件完整性。
ora-15335 出现时，基本可以断定是 asm 元数据已损坏，不是配置或权限问题，强行 alter diskgroup ... mount 会失败，必须从底层恢复元数据或抢救文件。
确认是否真为元数据损坏，而非发现路径问题
很多“挂载失败”其实是 asm_diskstring 配置错误或磁盘路径重复导致的误判，先排除这类低级但高频的问题：
- 检查
asm_diskstring是否包含重复路径（如同时写了/dev/mapper/CRSp1和/dev/dm-23），这会导致 ASM 报ERROR: detected duplicate paths to the same disk，并最终触发ORA-15063 - 用
kfod手动验证磁盘可见性：kfod disk=ALL dscv=TRUE，看输出中磁盘的HEADER_STATUS是MEMBER还是CANDIDATE或PROVISIONED；CANDIDATE是典型磁盘头被覆盖的信号 - 查告警日志里是否有
ORA-15196（如invalid ASM block header [kfc.c:26076] [endian_kfbh]），这是磁盘头字节序或校验失败的铁证
如果看到 ORA-15335 + CANDIDATE + ORA-15196 组合，就不用再折腾参数了，直接进恢复流程。
用 KFED 读磁盘头判断损坏范围
KFED 是唯一能直接读取 ASM 磁盘 AU 0/block 0 的工具，它不依赖 ASM 实例，适合在挂载前诊断：
- 先备份磁盘头（务必！）：
dd if=/dev/asm-disk1 of=/backup/disk1_head.img bs=1024k count=10 - 用
kfed read /dev/asm-disk1查关键字段：dsknum、grpname、fgname、ausize；若这些字段全为 0 或乱码，说明磁盘头已损毁 - 重点看
chksum和incarn：校验和不匹配（chksum != computed）或incarn为 0，基本可判定头块不可信 - 若仅一块盘头坏，且磁盘组是 NORMAL 或 HIGH 冗余，可能还能强制挂载；但若多块盘头损坏（尤其含 PST 所在盘），
amdu是更稳妥的选择
注意：KFED 不能修复，只用于诊断。别在生产盘上跑 kfed repair —— 官方明确不支持在线修复头块。
用 AMDU 提取数据文件绕过挂载
当元数据损坏严重、无法重组磁盘组时，AMDU 是最实用的“抢救”工具。它不依赖 ASM 实例，直接扫描磁盘内容提取文件：
- 确保
ORACLE_HOME指向 Grid Infrastructure（不是 RDBMS），否则amdu可能找不到 ASM 库 - 执行提取命令：
amdu -diskstring '/dev/asm*' -extract 'DATA.*' -destination /recovery；其中DATA.*是磁盘组名通配，实际可用amdu -diskstring ... -list先列出可用 DG - 提取出的文件名形如
DATA.258.764071447，需结合asmcmd ls -l（若还能进）或历史 RMAN 日志反推原始文件名与类型（datafile、spfile、controlfile） - 提取后用
strings或od -c快速验证文件头是否有效（如 datafile 应含ORCL或ORA字样，spfile 含SPFILE）
AMDU 不保证 100% 提取所有文件，尤其当 AU 分配表（AT）也损坏时，部分文件可能截断。此时需配合底层解析工具（如北亚的 ASM 解析器）做二次恢复。
恢复后验证文件完整性再导入
从 AMDU 或其他工具导出的文件，不能直接扔进新库启动 —— 必须验证其结构有效性：
- 对控制文件：用
strings查看是否含有效 checkpoint 记录；或尝试sqlplus / as sysdba后STARTUP NOMOUNT+RESTORE CONTROLFILE FROM ...测试能否识别 - 对数据文件：用
RMAN做快速校验：RMAN TARGET / CATALOG ... VALIDATE DATAFILECOPY '/recovery/DATA.258.764071447';；报ORA-19566表示坏块超限，需底层解析 - 对 spfile：用
strings提取文本参数后重建，或用CREATE SPFILE FROM PFILE方式还原 - 若发现关键文件（如 system01.dbf）损坏，不要强启库，应转向使用 Oracle 解析工具逐块提取记录，按表导出再
INSERT /*+ APPEND */导入新库
最易被忽略的一点：ASM 元数据损坏往往伴随底层存储异常（比如 SA 误对 ASM 盘执行 mkfs）。恢复完后，必须检查存储链路、多路径配置、以及所有节点的 udev 规则是否一致 —— 否则下次重启还会掉盘。
