前几天一朋友的客户数据库出现故障，现象的有2个datafile的文件头彻底损坏，有可能是硬件问题导致。
当时由于是windows环境，通过远程桌面操作，太卡，加上接手之前已经有人经过一系列的操作，导致恢复
相对麻烦，我采取的方式是利用他们之前create 的datafile，借助bbed修改ckpt信息，然后将库先open后。
最后再借助数据抽取软件将备份的损坏datafile数据抽取出来，然后直接加载到数据库中。

这里我来使用vm模拟下如果仅仅是datafile header block损坏的情况下，如何去手工恢复？当然，如果还有
其他block损坏，比如datafile header前面的bitmap block，那么恢复就相当复杂了。

—先模拟文件头损坏的情况

此时启动数据库，你会遇到类似如下错误：

当然我这里模拟有点绝对了，部分情况下，这种情况下是可以recover的。如果说文件头block彻底损坏完了。是不能直接进行修复的。
如果你有备份，那么你可以从备份里面将该datafile restore 出来，然后再去进行recover，这样是的。

上次遇到的情况下，在我接手之前，已经有人重建过datafile，且重建过controlfile(原始文件没有备份).

类似的操作:alter database create datafile ‘/home/ora10g/oradata/roger/roger01.dbf’. 当然，这个步骤也需要你先
重建controlfile或者使用较旧的controlfile来替换当前的controlfile，不然你会遇到这样的错误：

针对这种情况下，创建datafile后，其scn是非常老的，如果你需要进行recover，那么需要从该scn开始至今的所有archivelog。

在这样的情况下起手就可以手工去修复数据文件头，如果是损坏很严重，那么你可以偷懒，从其他datfile copy过去，然后再修改。

+++++++++++ 如下是整个修复的过程，我这里来简单演示一下。

这里有个关键性的问题是，我们需要修改哪些地方？ 这就需要你对datafile header的结构相对熟悉了。 dbsanke很早之前写过一篇，大家可以参考下。

++++++ 第一修改的地方：rdba_kcbh

这里是0x0100001,表示file 4 block 1，我们要将其改成正确的值：file 2 block 1 。 后面block号不变，即应该是0x00800001

++++++ 第2个修改的地方：kccfhfsz 即文件大小

首先你可以从os上去查看数据文件的实际大小，如下：
[ora10g@killdb roger]$ ls -ltr roger01.dbf
-rw-r—– 1 ora10g oinstall 10493952 Jan 28 06:31 roger01.dbf

不过需要注意一点的是，dbfile的大小应该你操作系统上看到的实际大小减去一个db block_size，因为还存在一个os block header。

++++++ 第3个修改的地方：kccfhfno datafile文件号

++++++ 第4个修改的地方：kscnbas v$datafile.create_change#

++++++++ 第5个修改的地方：kcvfhcrt 表示v$datafile.create_time

++++++++ 第6个修改的地方：kcvfhtsn 表示表空间号v$datafile.ts#

++++++++ 第7个修改的地方： kcvfhrfn v$datafile.rfile# 即相对文件号

+++++++++ 第8个修改的地方：kcvfhtnm 表空间名称即v$tablespace.name

这里补充一下，如果你的表空间名称跟实际不符，可能还需要修改kcvfhtln，表示长度。我这里是ROGER即为5.

最后我们来尝试下：

看来还有地方不对，我们来查询下v$datafile看下信息：

可以看到检查点信息不一致，这是因为开始我为了演示模拟中途open过了一次。

而目前datafile 2的实际scn跟实际不符：

我们可以看到，checkpoint scn和time都不对，所以还需要修改下：

修改完成之后我们可以通过dbv来检查下，看看文件头修改是否都正确，如下：