欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  数据库

某客户ERP系统Oracle 8.0.5恢复一例

程序员文章站 2024-04-04 12:08:23
...

本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger 的Oracle技术博客 本文链接地址: 某客户ERP系统Oracle 8.0.5恢复一例 某客户的ERP数据库出现异常,数据库版本比较老,是Oracle 8.0.5。 问题本身并不复杂,简单记录一下。 主要的问

本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger 的Oracle技术博客

本文链接地址: 某客户ERP系统Oracle 8.0.5恢复一例

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

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

Thu Dec 25 13:29:42 2014
ORACLE Instance PROD (pid = 78) - Error 1115 encountered while recovering transaction (28, 23).
Thu Dec 25 13:29:42 2014
Errors in file /u04/dbcommon/PROD/udump/prod_ora_23181.trc:
ORA-01115: IO error reading block from file 2 (block # 262144)
ORA-01110: data file 2: '/u03/oradata/PROD/rbs1.dbf'
ORA-27072: skgfdisp: I/O error
SVR4 Error: 2: No such file or directory
Additional information: 262143
ORACLE Instance PROD (pid = 78) - Error 1115 encountered while recovering transaction (28, 23).
Thu Dec 25 13:30:04 2014
Errors in file /u04/dbcommon/PROD/udump/prod_ora_23181.trc:
ORA-01115: IO error reading block from file 2 (block # 262144)
ORA-01110: data file 2: '/u03/oradata/PROD/rbs1.dbf'
ORA-27072: skgfdisp: I/O error
SVR4 Error: 2: No such file or directory
Additional information: 262143

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

---异常文件
$ dd if=rbs1.dbf.bak bs=8192 count=1 | od -x |head -10
1+0 records in
1+0 records out
0000000 0000 0000 0000 2000 0007 f800 5a5b 5c5d
0000020 0000 0000 0000 0000 0000 0000 0000 0000
*
0020000
 
----正常文件
$ dd if=oed3.dbf  bs=8192 count=1 | od -x |head -10
1+0 records in
1+0 records out
0000000 0000 0000 0000 2000 0000 1e00 5a5b 5c5d
0000020 0000 0000 0000 0000 0000 0000 0000 0000
*
0020000

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

********************************************************************************
UNDO BLK:
xid: 0x001c.017.0000c361  seq: 0x88ef cnt: 0x4e  irb: 0x1   icl: 0x0   flg: 0x0000
 
 Rec Offset      Rec Offset      Rec Offset      Rec Offset      Rec Offset
---------------------------------------------------------------------------
0x01 0x1f88     0x02 0x1f2c     0x03 0x1e9c     0x04 0x1e44     0x05 0x1dec
。。。。。。
0x47 0x03c0     0x48 0x0364     0x49 0x02d4     0x4a 0x027c     0x4b 0x0224
0x4c 0x01c4     0x4d 0x0168     0x4e 0x00d8
 
 
*-----------------------------
* Rec #0x1  slt: 0x17  objn: 202838(0x00031856)  objd: 202838  tblspc: 22(0x00000016)
*       Layer:  10 (Index)   opc: 22   rci 0x00
Undo type:  Regular undo   Last buffer split:  No
Temp Object:  No
rdba: 0x0083ffff
*-----------------------------
index undo for leaf key operations
KTB Redo
op: 0x02  ver: 0x01
op: C  uba: 0x0083ffff.88ef.4b
Dump kdilk : itl=3, kdxlkflg=0x1 sdc=0 indexid=0x18816b90 block=0x05c12678
restore leaf row (clear leaf delete flags)
key :(14):  04 c3 02 24 32 05 3c 3d 49 4a 66 02 c1 2c
keydata/bitmap : (6):  19 40 79 da 00 1d

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

Error 1115 encountered while recovering transaction (28, 23)

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

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

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

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

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

SVRMGR> insert /*+append */into  inv.MTL_TRANSACTION_ACCOUNTS_BAK select /*+parallel(t,4)*/* from inv.MTL_TRANSACTION_ACCOUNTS t;
ORA-12801: error signaled in parallel query server P001
ORA-01115: IO error reading block from file 94 (block # 262141)
ORA-27072: skgfdisp: I/O error
SVR4 Error: 25: Inappropriate ioctl for device
Additional information: 262141
ORA-01115: IO error reading block from file 94 (block # 262141)
ORA-27072: skgfdisp: I/O error
SVR4 Error: 25: Inappropriate ioctl for device
Additional information: 262141

实际上,这个表,在我处理之前,直接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年了,也正是够老的了。

Related posts:

  1. win 环境 O/S-Error: (OS 23) 数据错误(循环冗余检查) —恢复
  2. 不完全详解os block header
  3. 使用ODU恢复9208数据库一例
  4. windows Oracle数据文件大小为0的恢复case