能修，因ASM元数据损坏多为磁盘头、PST、FST或AT表局部出错，非物理磁盘故障；应先查v$asm_disk与alert日志定位层级，再用kfed repair（须指定正确ausz）修复磁盘头，或amdu提取数据，严禁盲目dd清盘或重建磁盘组。
ASM元数据损坏不是“磁盘坏了”，而是ASM找不到自己该读的那几块关键AU——磁盘头、PST、FST或AT表出错，导致磁盘组无法挂载、文件不可见或rebalance卡死。修复核心是分层定位：先确认损坏点在哪一层，再用对应工具干预，不能一上来就dd清盘或重建磁盘组。
查v$asm_disk和alert日志快速定位损坏层级
登录 ASM 实例执行：SELECT path, header_status, mode_status, state FROM v$asm_disk; 结合告警日志中的错误码判断问题类型：
-
header_status = CANDIDATE或FORMER：磁盘头被覆盖（如误建LVM/分区），需kfed修复 -
header_status = PROVISIONED但磁盘组仍无法MOUNT：可能是PST/FST损坏，需amdu提取或kfed检查AU 1 - 日志中出现
ORA-15335: ASM metadata corruption detected+AMDU-00209: Corrupt block found：已定位到具体AU/block，必须用amdu -extract抢救数据 - 查询
v$asm_diskgroup发现state = DISMOUNTED且无磁盘显示：不是元数据损坏，而是asm_diskstring未生效或权限缺失，先别碰kfed
磁盘头损坏时必须先备份再kfed repair
磁盘头位于AU 0的block 0，一旦误操作会永久丢失磁盘组归属信息。修复前务必执行完整备份：
- 备份整个磁盘头区域：
kfed read /dev/mapper/datap1 blkn=0 aus=4194304 > datap1_hdr.bak（aus必须与原磁盘一致） - 若
header_status = CANDIDATE，大概率是有人在设备上建了分区表，用fdisk -l /dev/mapper/datap1确认；存在则用dd if=/dev/zero of=/dev/mapper/datap1 bs=1024 count=100清MBR，再kfed repair -
kfed repair命令必须带aus参数：kfed repair /dev/mapper/datap1 aus=4194304，缺省值会导致失败 - 修复后
header_status应变为MEMBER或PROVISIONED，此时才能执行ALTER DISKGROUP DATA MOUNT
AMDU是抢救已损坏磁盘组内数据的最后手段
当v$asm_disk能识别磁盘但ORA-15335报错，且kfed检查磁盘头正常时，说明损坏发生在更高层（如FST或文件目录块）。此时不能尝试ALTER DISKGROUP ... FORCE，而应立即用amdu导出：
- 先确认磁盘路径是否被识别：
amdu -diskstring '/dev/mapper/datap1' -list，输出应含DATA磁盘组信息 - 提取整个磁盘组所有文件：
amdu -diskstring '/dev/mapper/datap1' -extract DATA，结果存入当前目录amdu*/*子目录 -
amdu不依赖ASM实例运行，即使磁盘组完全DISMOUNTED也能工作，但要求设备对grid用户可读 - 导出的文件名是
DATA.258这类编号格式，需结合amdu -dump或strings识别实际数据文件类型
真正棘手的是PST损坏——它不报明确错误，只表现为磁盘组挂载后部分文件丢失或rebalance反复失败。这种情况下kfed读AU 1可能看到KFBTYP_PST块校验失败，但Oracle官方不提供PST修复工具，只能靠amdu抢救数据后，在新环境重建磁盘组再导入。
