某客戶ERP系統Oracle8.0.5恢復一例

來源：懂視網責編：小采時間：2020-11-09 13:01:12

某客戶ERP系統Oracle8.0.5恢復一例

某客戶ERP系統Oracle8.0.5恢復一例:本站文章除注明轉載外，均為本站原創：轉載自love wife love life —Roger 的Oracle技術博客本文鏈接地址: 某客戶ERP系統Oracle 8.0.5恢復一例某客戶的ERP數據庫出現異常，數據庫版本比較老，是Oracle 8.0.5。問題本身并不復雜，簡單記錄一下

推薦度：

點擊下載本文 文檔為doc格式

導讀某客戶ERP系統Oracle8.0.5恢復一例:本站文章除注明轉載外，均為本站原創：轉載自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。問題本身并不復雜，簡單記錄一下。主要的問

本站文章除注明轉載外，均為本站原創：轉載自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年了，也正是夠老的了。