某客户数据库崩溃同时dmp损坏的恢复案例

某客户的一个库系统损坏,导致oracle 崩溃,最后通过安全模式将数据文件拷贝出来,发现无法启动,非归档环境,

而且只有dmp 备份,之前他们通过dmp 备份进行了恢复,但是发现部分dmp 可能存在问题,导致部分表无法恢复,又尝试使用ODU进行数据文件的抽取,也发现部分表无法抽取(可能是system损坏较为严重,dbv检测有1000多个坏块)。

如下是尝试open时的alert log信息:

很明显,Oracle 在执行递归SQL的适合报错了,而且遇到了坏块。通过dbv检测,我发现存在大量的坏块,而且部分块还是连续损坏,极有可能是某个extent都损坏了。如下是dbv的检测结果:

我们看到,部分坏块是连续的,这种情况处理就比较麻烦了。开始我尝试通过一些其他手段想把库先拉起来,发现不行,如下是10046 trace的内容:

我们可以看到,在访问某个block的适合出问题了,而且该block后面连续几个都是损坏的。我尝试bbed copy修改了几个block都不行。最后发现其实这个递归SQL,可以想办法绕过去的,及通过修改Oracle 二进制文件的方法,可惜的是客户

的机器上已经跑了一个库了,无法停,因此这种方法也就作罢;当然或许还能通过gdb来实现。总的来讲比较麻烦。

考虑到他们本身具有dmp 备份,因此直接dul 抽取dmp 即可,把需要的表弄出来就完了。

如下是dul 抽取dump的步骤:

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注