AMDU不能修复元数据损坏，仅能绕过损坏提取可用数据文件；前提是磁盘物理可读、AU未被覆盖、FILENUMBER 1的指针未彻底损毁，且需确认磁盘头可读、diskgroup可识别、AMDU版本匹配。
amdu 不能修复元数据损坏，只能绕过它提取可用数据文件；前提是磁盘物理可读、au未被覆盖、filenumber 1 的指针没彻底损毁。
AMDU 提取前必须确认的三件事
AMDU 是个“只读抽取器”，不校验逻辑一致性，也不重建 ASM 结构。它依赖磁盘上残留的元数据片段（尤其是 disk header 和 PST）来定位文件位置。如果这些关键块被清零或写坏，amdu -extract 会直接报错退出。
- 用
kfed read dev=/dev/asm-diskX检查磁盘头是否可读：重点看输出中是否有kdskhdbk（disk number）、kfdhdbgrp（group name）、kfdhdbau（AU size）字段值正常 - 运行
amdu -diskstring '/dev/asm-disk*' -list，确认能否识别出 diskgroup 名称和磁盘列表；若返回空或报AMDU-00204: No disks found，说明磁盘头已不可识别，AMDU 失效 - 检查
ORACLE_HOME/bin/amdu是否存在且版本匹配：12c 的 AMDU 不兼容 11g 的 AU 布局（尤其当 AU=8M 或 16M 时），需用同版本 Grid Infrastructure 自带的 AMDU
amdu -extract 命令的关键参数与避坑点
AMDU 抽取不是“一键恢复”，而是按文件号 + 磁盘号 + AU 号拼接原始块。错误的参数会导致文件截断、偏移错位甚至生成无法识别的二进制垃圾。
-
amdu -diskstring '/dev/asm-disk[efg]'：必须用通配符或完整路径，不能省略引号；路径末尾不加斜杠，否则报AMDU-00201 -
-extract DATA.258中的DATA.258是 ASM 内部文件名格式（diskgroup.file_number），不是 OS 路径；该编号来自 ASM 元数据快照，若 PST 损坏，需先用amdu -list输出反查，不能凭记忆填写 - 默认 AU 大小为 1MB；若实际是 4MB（常见于 12c RAC），必须显式加
-au 4194304，否则所有block定位全错，抽出来的文件dbv校验必失败 - 抽取过程不校验 checksum，抽完务必用
dbv file=xxx.dbf blocksize=8192验证；若大量DBV-00200（bad header）或DBV-00201（corrupt block），说明 AU 偏移不准或文件碎片不连续
当 amdu -extract 报 AMDU-00209（Corrupt block found）时怎么办
这个错误表示 AMDU 在扫描 AU 过程中读到了类型标识异常的 block（比如本该是 metadata block 却读出全是 0x00）。它不等于数据不可用，只是 AMDU 放弃了当前 AU 的解析——但后续 AU 可能仍完好。
- 加
-noreport参数强制继续：例如amdu -diskstring '/dev/asm-diskf' -extract DATA.258 -noreport，避免因单个坏块中断整个文件抽取 - 改用
-dump模式人工定位：先amdu -diskstring ... -dump DATA.258 > dump.log，在日志里找 “extent map” 段，手动挑出连续、无 corruption 标记的 AU 区间，再用dd按 AU 号拼接（如dd if=/dev/asm-diskf bs=4194304 skip=96 count=128 of=datafile_part1） - 别信 “自动跳过”：AMDU 不会智能跳过坏 AU 并重对齐，它只是停止；若 extent 分布稀疏（如镜像+条带化），坏 AU 后面的 extent 很可能也失效，必须结合
kfed find手动验证每个 AU 的 block type
真正麻烦的是 FILENUMBER 1（ASM disk header + PST 所在文件）彻底损毁——此时 AMDU 连 diskgroup 名都列不出来，amdu -list 返回空。这种情况下，AMDU 已无用武之地，必须切换到 prmscan 或 prm-dul 这类基于块签名（如 0x00000001 0x00000000 + 0x00000000 0x00000000）逐扇区扫描的工具，代价是耗时数小时起，且无法保证所有表空间都能完整重组。
