ORA-15335出现时基本可断定ASM元数据损坏，需先排除asm_diskstring重复路径等配置错误，再通过kfod查HEADER_STATUS为CANDIDATE、告警日志含ORA-15196确认损坏，继而用KFED读取并验证磁盘头（含备份块blkn=2046），单盘损坏可用kfed repair恢复，多盘或PST盘损坏则须用AMDU提取文件。
确认磁盘头损坏而非配置错误
ora-15335 出现时，基本可以断定是 asm 元数据已损坏，不是 asm_diskstring 配置或权限问题。强行 alter diskgroup mount 会失败，必须先排除低级误判：
- 检查
asm_diskstring是否含重复路径（如同时写了/dev/mapper/CRSp1和/dev/dm-23），这会触发ORA-15063和 “duplicate paths” 报错 - 用
kfod disk=ALL dscv=TRUE查磁盘可见性：若输出中HEADER_STATUS是CANDIDATE或PROVISIONED，而非MEMBER，说明磁盘头已被覆盖 - 查告警日志是否有
ORA-15196（如invalid ASM block header [kfc.c:26076]），这是头块字节序或校验失败的铁证
看到 ORA-15335 + CANDIDATE + ORA-15196 组合，就不用再调参数了，直接进恢复流程。
用 KFED 读取并验证磁盘头状态
KFED 是唯一能绕过 ASM 实例、直接读 AU 0/block 0 的工具，但只用于诊断，不能在线修复：
- 务必先备份磁盘头：
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，头块不可信 - 注意：10.2.0.5+ 版本在第二 AU 的倒数第二个 block（如 AU=4M 时是 block 2046）存有头块备份，可用
kfed read /dev/asm-disk1 blkn=2046验证是否完好
用 KFED repair 恢复磁盘头（仅限单盘损坏）
当仅少数磁盘头损坏（尤其 NORMAL/HIGH 冗余磁盘组），且备份块完好的情况下，可尝试 kfed repair：
- 必须指定 AU 大小，否则非默认值（如 4M）会报错：
kfed repair /dev/asm-disk1 aus=4194304 - 修复后立即验证：
kfed read /dev/asm-disk1 | egrep 'dsknum|grpname|hdrsts'，确认hdrsts变为KFDHDR_MEMBER - 切勿在生产盘上运行
kfed repair前未备份 —— 官方明确不支持在线修复，操作失误无法回退 - 若多块盘头损坏，或 PST 所在盘（通常为磁盘组第 0、1、2 号盘）受损，
kfed repair失效，应转向AMDU提取文件
用 AMDU 抢救数据（元数据彻底失效时）
当磁盘组无法重组、kfed repair 无效或不敢贸然操作时，AMDU 是最稳妥的“绕过挂载”抢救手段：
- 确保
ORACLE_HOME指向 Grid Infrastructure 目录，否则amdu会因找不到 ASM 库而失败 - 先列出可用磁盘组：
amdu -diskstring '/dev/asm*' -list，再提取目标文件：amdu -diskstring '/dev/asm*' -extract 'DATA.*' -destination /recovery - 提取出的文件名形如
DATA.258.764071447，需结合历史 RMAN 日志或asmcmd ls -l（若还能进）还原原始文件名和结构 - AMDU 不依赖 ASM 实例，但对 AU 大小和块偏移敏感；若遇到
AMDU-00209: Corrupt block found，说明底层数据块也损坏，需交叉比对多块盘提取结果
真实场景里，kfed repair 看似快，但要求你准确识别哪块盘坏了、AU 多大、备份块是否可用；而 AMDU 虽慢，却更鲁棒——它不修元数据，只捞数据，反而在多数严重损坏案例中成了最后防线。
