某客户的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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

ThuDec2513:29:422014

ORACLEInstancePROD(pid=78)-Error1115encounteredwhilerecoveringtransaction(28,23).

ThuDec2513:29:422014

Errorsinfile/u04/dbcommon/PROD/udump/prod_ora_23181.trc:

ORA-01115:IOerrorreadingblockfromfile2(block# 262144)

ORA-01110:datafile2:'/u03/oradata/PROD/rbs1.dbf'

ORA-27072:skgfdisp:I/Oerror

SVR4Error:2:Nosuchfileordirectory

Additionalinformation:262143

ORACLEInstancePROD(pid=78)-Error1115encounteredwhilerecoveringtransaction(28,23).

ThuDec2513:30:042014

Errorsinfile/u04/dbcommon/PROD/udump/prod_ora_23181.trc:

ORA-01115:IOerrorreadingblockfromfile2(block# 262144)

ORA-01110:datafile2:'/u03/oradata/PROD/rbs1.dbf'

ORA-27072:skgfdisp:I/Oerror

SVR4Error:2:Nosuchfileordirectory

Additionalinformation: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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

---异常文件

$ddif=rbs1.dbf.bakbs=8192count=1|od-x|head-10

1+0recordsin

1+0recordsout

000000000000000000020000007f8005a5b5c5d

000002000000000000000000000000000000000

*

0020000

----正常文件

$ddif=oed3.dbfbs=8192count=1|od-x|head-10

1+0recordsin

1+0recordsout

0000000000000000000200000001e005a5b5c5d

000002000000000000000000000000000000000

*

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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

********************************************************************************

UNDOBLK:

xid:0x001c.017.0000c361seq:0x88efcnt:0x4eirb:0x1icl:0x0flg:0x0000

RecOffsetRecOffsetRecOffsetRecOffsetRecOffset

---------------------------------------------------------------------------

0x010x1f880x020x1f2c0x030x1e9c0x040x1e440x050x1dec

。。。。。。

0x470x03c00x480x03640x490x02d40x4a0x027c0x4b0x0224

0x4c0x01c40x4d0x01680x4e0x00d8

*-----------------------------

*Rec#0x1  slt: 0x17  objn: 202838(0x00031856)  objd: 202838  tblspc: 22(0x00000016)

*Layer:10(Index)opc:22rci0x00

Undotype:RegularundoLastbuffersplit:No

TempObject:No

rdba:0x0083ffff

*-----------------------------

indexundoforleafkeyoperations

KTBRedo

op:0x02ver:0x01

op:Cuba:0x0083ffff.88ef.4b

Dumpkdilk:itl=3,kdxlkflg=0x1sdc=0indexid=0x18816b90block=0x05c12678

restoreleafrow(clearleafdeleteflags)

key:(14):04c3022432053c3d494a6602c12c

keydata/bitmap:(6):194079da001d

上述的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

1

2

3

4

5

6

7

8

9

10

SVRMGR>insert/*+append */intoinv.MTL_TRANSACTION_ACCOUNTS_BAKselect/*+parallel(t,4)*/*frominv.MTL_TRANSACTION_ACCOUNTSt;

ORA-12801:errorsignaledinparallelqueryserverP001

ORA-01115:IOerrorreadingblockfromfile94(block# 262141)

ORA-27072:skgfdisp:I/Oerror

SVR4Error:25:Inappropriateioctlfordevice

Additionalinformation:262141

ORA-01115:IOerrorreadingblockfromfile94(block# 262141)

ORA-27072:skgfdisp:I/Oerror

SVR4Error:25:Inappropriateioctlfordevice

Additionalinformation: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年了，也正是够老的了。