某客户ERP系统Oracle 8.0.5 数据库恢复案例

某客户的ERP数据库出现异常,数据库版本比较老,是Oracle 8.0.5。 问题本身并不复杂,简单记录一下。

主要的问题是客户的应用访问报错,通过分析客户传的alert log发现出现了大量的IO错误,如下:

从alert log 来看,上述报错的文件出现IO error,实际上该文件是确实存在的。开始我以为有可能是数据文件头的
os block 损坏了,通过dd dump分析发现是OK,如下:

同时,从报错来看,提到了一个block,查看trace可以看到该block的内容如下:

上述的dump内容非常简单。我们回头来看下前面的错误:

Error 1115 encountered while recovering transaction (28, 23)

首先我们需要明白,这里的28,,23分别代表什么含义 ?

正常情况下,这里的28表示回滚段编号,23表示事务槽编号。 通过检查发现实际上这里的信息是不对的。
客户的系统中根本不存在这个回滚段。通过block号,我们定位到实际上是第4号回滚段。

因此要解决这个回滚段事务的问题,就很简单了,通过_corrupted_rollback_segments=RBS4 然后强制drop即可。

另外,由于这里事务涉及的操作,其实是针对Index的操作,因此。我们drop完成之后,还需要重建相关的Index。

当处理完这个之后,客户反馈另外一个数据文件也有问题,当操作某个表时,会出现异常,如下:

实际上,这个表,在我处理之前,直接count(1)操作,都会报上面的错误。经查,这是Oracle 805的bug导致。

通过调整disk_async_io=false,以及db_file_multiblock_read_count为16,解决了这个问题。

虽然可以进行count,然而客户反馈业务操作仍然报错。最后我们发现,这可能是oracle 805的bug导致,当数据文件大小
超过2GB时,会出现异常。实际上,我在进行dbv检查时,该数据文件都会报错。

最后我们通过cats重建表,然后重建index解决了该问题。

备注:805版本中,rename table语法很坑爹,必须这样:

alter table roger.test rename to test_new;

这个系统将近20年了,也正是够老的了。

发表评论

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