dd破坏包含50多个pdb的asm 磁盘组恢复

惜分飞 — Sat, 27 Jun 2026 14:00:11 +0000

前段时间刚刚恢复了一个客户dd了34个磁盘中的2个磁盘的1-2G多的数据（在生产环境错误执行dd命令破坏asm磁盘故障恢复），这次又遇到一个客户dd了asm 的两个磁盘的100m和10m，这次故障麻烦的是由于dd了disk 0和disk 1，ausize为4M，有50多个pdb在该磁盘组中，相对恢复比较麻烦，通过不懈努力，最后终于最大限度恢复客户数据，避免了进一步的损失
故障误操作
近期又一个可以误执行了dd命令，破坏了生产库的两个asm disk磁盘

上述截图中可以确认两个信息
1.sdh盘被dd掉了10m，sdg盘被dd掉了100M
2.sdg对应的是asm-data1，sdh对应的是asm-data2
dd误操作之后，data磁盘组开始报错，然后直接dismount.

分析原磁盘组中asm磁盘情况
1.确定损坏磁盘在磁盘组中位置
通过asm的alert日志分析损坏的盘对应的磁盘组信息

基于这个信息，我们可以确认asm-data1 对应的是DATA磁盘组的disk 0，asm-data2对应的是DATA磁盘组的disk 1，也就是说现在DATA磁盘组的0号盘被dd了100M，1号盘被dd了10m
2.确认ausize大小
通过分析该磁盘组的其他磁盘确认ausize大小
kfdhdb.ausize: 4194304 ; 0x0bc: 0×00400000
可以确认该磁盘组的au大小为4M
3.磁盘组后续进行了一次加盘扩容

在25年6月份，对data磁盘组加了三块盘
4.sdh(asm-data2)磁盘还被加入到了arch磁盘组中

比较幸运由于在另外一个节点上sdh磁盘权限没有正确修改，导致该增加没有完全成功，也就是该磁盘没有被reblance（如果加入成功并正常reblance，那后果比现在严重很多）
5.通过结合asm日志以及kfed，磁盘物理大小等信息，并且通过kfed构造出来损坏的磁盘头信息，列出故障之前DATA磁盘组所有磁盘的情况（为了避免udev别名带来的影响，我直接使用物理磁盘名称来显示）

客户现场情况说明
1.客户有一个大概1年多之前的dataguard（后续没有继续同步），已经进行了failover激活
2.客户的备份系统中有一个大概1个月之前的备份，但是备份库缺少归档，我接手之时，已经被维护厂商强制拉起
3.在我恢复之前，有专业的工程师已经对其这个现场进行了分析，但是没有拿出好的恢复方案
恢复难点说明
1.该磁盘组的disk 0 被dd掉了100M，这个导致kfdhdb.f1b1locn记录被清空，也就无法获取到存储指向ASM file 1 文件目录表，这个值虽然被清空，但是根据经验或者对比其他磁盘组的disk 0 可以确认指定aun为10
2.f1b1locn指向的au中存储中asm元数据1-255以及256-1023的file的前面60个au的extent映射表，由于这个在aun为10（也就是aun*aus=40M）的位置，但是这个位置也已经被dd掉了，从原理上业务文件256-1023的前面60个au的extent映射表彻底丢失
3.通过工具扫描，发现存储别名信息的au也在disk 0的前面100M之内(也被dd掉了),导致通过别名直接定位文件的起点的恢复思路也不可行，而且别名丢失导致以别名的数据文件后续识别有一定的难度（无法获取asm里面文件的完整路径）
4.该库有50多套pdb组成，也就意味着通过数据库碎片扫描的方式无法恢复（因为每个pdb里面都是由默认的种子创建而成，也就意味着rfile 1,4,9是重复的）
5.由于中途加过一次磁盘，因引起这个asm里面的文件进行重新reblance，使得部分文件同一个block记录在不同磁盘的au上(数据文件块可能重复)
6.由于该磁盘组中asm disk 大小不等，导致文件au分布在各个磁盘上不均匀，无明显规律可循
恢复操作
1.通过kfed对损坏的asm-data1、asm-disk2的磁盘头进行构造，便于后续的恢复工具识别
2.通过工具对data中所有磁盘进行扫描，主要扫描文件extent映射表信息和ACD中关于asm文件的分配信息
2.1> 通过对这些信息进行综合分析，确认asm file >=1024的文件的extent映射表信息完整，数据可以直接恢复，效果类似

2.2> 对于256-1023号文件通过asm file的extent信息缺少0-59 au的数据，结合acd中获取的部分au分配信息，可以尽可能完整的恢复出来这些数据(由于disk 0中的acd信息丢失,所以不是100%完整)

3.对于绝对文件号非1,4,9的文件，而且asm file 小于1024的数据文件，结合rdba碎片重组的方式再一次进行恢复，避免上面2.2中恢复中前面240M(60个au)，有部分au信息丢失导致文件不完整的情况
通过上述多种方法恢复，整体恢复数据文件类似（由于文件较多，存放多个目录和根据规则取了多种名字）

4.由于asm的文件目录，别名信息全部丢失，而且该库有50多个pdb，无法确认恢复出来的上千个文件和pdb对应的关系，对于这种情况，临时写了一个小程序，对这些文件进行读取，获取file#,rfile#,ts#,tsname,文件大小,dbid,dbname,scn等信息(obet(Oracle Block Editor Tool)第二版发布

通过把这些信息和历史的控制文件中的信息进行匹配，确认各个文件所属的pdb关系
5.通过4中获取的文件和pdb对应关系然后通过dbms_pdb.recover包实现把恢复的文件插入到新的cdb库中，在这个插入和open库过程中遇到各种错误，都一一解决

6.最终完成客户数据恢复要求（为了保证数据不被再次修改，客户要求所有恢复的pdb不能打开到读写模式）

然后由客户的运维厂商或者应用厂商把需要的数据迁移或者整合到新库中并恢复业务，完成本次恢复任务

惜分飞 » asm dd恢复

dd破坏包含50多个pdb的asm 磁盘组恢复