很多时候，我们面临一个问题，对于asm diskgroup中的数据文件，如果存在坏块，要么通过备份进行恢复要么进行blockrecover，除了这2种方法之外，对于绝大多数人来讲，我想都是没招儿了。其实不然，你还可以利用bbed来进行修复。这里我没有模拟坏块，仅仅是利用bbed来模拟直接修改asm diskgroup中的表数据，方法类似。

++++创建测试表

这里我需要将第3条数据100修改为99.

通过将该block copy到文件系统，然后bbed修改数据，然后再copy到asm diskgroup。

++++copy block to filesystem

+++++使用bbed 修改数据

修改完成之后，我们需要将block从文件系统copy回asm diskgroup中，如下：

++++copy block to asm diskgroup

验证数据是否修改成功，如下所示：

这里是利用了metalink的copy 脚本，其实我们也可以手工进行操作，dbsnake之前写过一篇文章，不过该文章
有点不够完整，这里我进行补充一下，搞个完整版本。

这里我的演示，主要通过将t0727表中的第3条数据通过bbed修改为98.如下是整个实验的过程。

而我们根据block进行计算，发现表表的数据应该在第一个au中，如下：

asm默认block是4096，一个AU容纳256个block，如果换成数据库的8192，那么则是128个block。

从上面的信息我们可以看出，该数据文件的第一个AU为275，而t0727表在第1个AU中，

根据这样的计算，那么该表t0727的实际位置为；

下面我们开始手工dd ASM disk中的该block到文件系统然后进行bbed修改，最后再dd回asm中。

注意，直接dd的block是没有os block 的，如果我们需要用bbed来进行修改，那么就需要为dd出来的block
构造一个os block块。 对于os block header的结构，很早之前我写过一篇文档。
这里我直接用之前asm copy脚本产生的文件来进行构造，构造的方法很简单，将os block header 进行dd，然后
dd拼接到需要修改的block上即可，如下是步骤：

如果不进行os block header的构造，那么bbed这里会出现问题，你看到的情况可能是这样的：

很明显，上面的信息是有问题的，下面我们通过bbed来进行修改。

我们通过bbed修改完成之后，需要再通过dd命令将block 还原到asm disk上，直接dd之前也需要先截取一下，否则
直接dd是会产生坏块的，如下：

最后来验证一下：

可以看到，我们已经成功将该表的第3条数据，通过bbed修改为98了。

说明：使用类似的方法来修复asm 坏块，思路完全一致，这里不再累述，本文仅供参考！