oracle中expdp 報錯ORA-7445的問題解決方案

某客戶說一套資料庫由於非順利關機重啟之後,進行資料匯出發現報錯，expdp無法正常工作，報錯之後直接退出：

處理物件類型 SCHEMA_EXPORT/JOB
. . 匯出了 "STATS"."T_REPORT_MONTH_TEMPS"              988.2 MB 1292221 行
ORA-39014: 一個或多個 worker 進程已過早地退出。
ORA-39029: worker 進程 1 (進程名為 "DW01") 過早地終止
ORA-31672: Worker 進程 DW01 意外停止。
 
作業 "SYS"."SYS_EXPORT_SCHEMA_04" 因致命錯誤於 23:58:10 停止
而檢查此時的alert log可以發現有如下類似的錯誤：

Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_dw01_28608.trc:
ORA-07445: 出現異常錯誤: 核心轉儲 [klufprd()+321] [SIGSEGV] [Address not mapped to object] [0x000000000] [] []

從上面的資訊我們可以得到如下幾個結論：

1、expdp的寫進程報錯，因為日誌產生是dw進程。
2、dw進程報錯的原因是遭遇了ora-07445 [klufprd()+321]錯誤。
3、對於[klufprd()+321] 這個函數，非常少見。但是從前面2點我們可以知道這肯定與buffer cache有關係。
所以要臨時解決這個問題也很簡單。通過alter system flush buffer_cache 重新整理緩衝之後，再次進行expdp操作.
後續客戶嘗試了之後，發現expdp 操作雖然仍然會報錯，但是expdp 不會異常終止，會繼續完成後面其他對象的匯出。

進一步分析報錯的資訊可以看到，有如下這樣的提示:

*** SESSION ID:(2760.1968) 2016-04-08 00:14:14.347
            row 01808438.0 continuation at
            file# 6 block# 33784 slot 14 not found
**************************************************
KDSTABN_GET: 0 ..... ntab: 1
curSlot: 14 ..... nrows: 14
**************************************************
*** 2016-04-08 00:14:14.348
ksedmp: internal or fatal error
ORA-00600: ÄÚ²¿´íÎó´úÂë, ²ÎÊý: [kdsgrp1], [], [], [], [], [], [], []
Current SQL statement for this session:
SELECT /*+NESTED_TABLE_GET_REFS+*/ "STATS"."T_REPORT_MONTH".* FROM "STATS"."T_REPORT_MONTH"
----- Call Stack Trace -----

很明顯，這裡提到這個這個表，恰好就是expdp報錯所遇到的表，只不過我們重新整理buffer cache之後，expdp可以跳過這個表繼續完成其他對象的匯出。
從上述的資訊來看，這裡存在錯誤。客戶也意識到，通過dbv 對資料檔案進行檢查，但是發現檔案並沒有損壞。
這裡我們要注意，dbv 同時是檢查物理壞塊，對於邏輯壞塊通常無能為力，當然塊內的邏輯錯誤，這類型的塊dbv是可以檢查出來的。
但是從這裡的資訊來看，Oracle發現所需要的這行記錄row 01808438.0 應該在file 6 block 33784 中找到，但是卻並沒有發現。
注意，這裡的file 6 block 33784 本身是完好的。
那麼這裡的row 01808438.0 表示什麼含義呢？
其實這是表示的nrid；這可以理解為一直指標；其中前面一部分是表現rdba地址，後面表現行編號。
如果要進一步分析為什麼會這個錯誤，我們怎麼辦呢？ 很簡單，分別將block 33784以及rdba 01808438（16進位) 進行dump。 如下是轉換的指令碼:

SQL>  SELECT dbms_utility.data_block_address_block(25199672) "BLOCK",
  2         dbms_utility.data_block_address_file(25199672) "FILE"
  3      FROM dual;
 
    BLOCK       FILE
---------- ----------
     33848          6

日誌報錯中提到的是row 01808438.0 ，那麼我們首先來分析file 6 block 33848的dump：

Block header dump:  0x01808438
 Object id on Block? Y
 seg/obj: 0xc03d01  csc: 0xb37.78b5ae28  itc: 3  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x1807d8a ver: 0x01 opc: 0
     inc: 0  exflg: 0
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x000a.02d.000cdc5c  0x00809c91.6507.21  --U-    2  fsc 0x0001.78b6a4b1
0x02   0x000a.014.000cdd00  0x00806957.650d.15  --U-    2  fsc 0x0000.78b6ec5d
0x03   0x000a.025.000cdd5d  0x00801e50.650f.0a  --U-    2  fsc 0x0000.78b71584
 
data_block_dump,data header at 0x1fb2f87c
===============
tsiz: 0x1f80
hsiz: 0x34
pbl: 0x1fb2f87c
bdba: 0x01808438
     76543210
flag=--------
ntab=1
nrow=17
frre=-1
fsbo=0x34
fseo=0xd2
avsp=0x33b
tosp=0x33c
0xe:pti[0]  nrow=17 offs=0
0x12:pri[0] offs=0x1e34
......
0x30:pri[15]    offs=0x6e2
0x32:pri[16]    offs=0x583
block_row_dump:
tab 0, row 0, @0x1e34
tl: 332 fb: --H-F--- lb: 0x0  cc: 79
nrid:  0x018083f8.e
col  0: [ 5]  c4 04 5a 27 1b
col  1: [ 7]  47 59 30 32 30 30 31
col  2: [ 4]  c3 15 11 04
col  3: [12]  31 38 37 33 34 34 32 30 30 30 30 36
col  4: [12]  31 34 30 34 34 34 32 30 30 30 30 31
col  5: [30]
......

上述類似表示的是rdba 地址01808438的第0行，也就是我們大家所理解的第一行。我們可以發現這行記錄中，行頭存在一個nrid地址。
說到nrid地址，這通常是針對行連結，行遷移才會遇到的一種情況。那麼這裡為什麼會出現呢？
行遷移幾種，最常見的一種其實是block內的。一個block中單條記錄的最大列數是255列，當一行記錄的列超過255時，其他的列資料庫會被oracle 分成另外一個row piece存在同一個block中（當然也有可能存到其他block）。
也就是說超過255列的行資料，會被分成多個row piece；而當我們讀取這個行資料時，怎麼知道是一個完整的整體呢？
答案就是nrid，oracle 通過nrid來將這多個row piece 串在一起，組成一個完整的行資料。
想到這一點，那麼我們再回頭去看下前面的錯誤。row 01808438.0 表示這個block的第0行，而該block的第0行所存在的nrid地址是：0x018083f8.e

那麼我們進一步到block 0x018083f8中去尋找第e行記錄，發現結果是這樣的：

Object id on Block? Y
 seg/obj: 0xc03d01  csc: 0xb37.78bb5e9f  itc: 3  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x1807d8a ver: 0x01 opc: 0
     inc: 0  exflg: 0
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x000a.013.000cdc01  0x01c02834.6573.33  --U-    2  fsc 0x0000.78cbf31d
0x02   0x000a.001.000cda7a  0x0080150a.64d3.21  C---    0  scn 0x0b37.78b584df
0x03   0x000a.01e.000cdade  0x00801510.64d3.13  C-U-    0  scn 0x0b37.78b99f21
 
data_block_dump,data header at 0x2b4fc709007c
===============
tsiz: 0x1f80
hsiz: 0x2e
pbl: 0x2b4fc709007c
bdba: 0x018083f80x018083f8
     76543210
flag=--------
ntab=1
nrow=14
frre=-1
fsbo=0x2e
fseo=0x568
avsp=0x53a
tosp=0x53a
0xe:pti[0]  nrow=14 offs=0
0x12:pri[0] offs=0x1d78
0x14:pri[1] offs=0x1c37
......
0x2a:pri[12]    offs=0x6c2
0x2c:pri[13]    offs=0x568
block_row_dump:
tab 0, row 0, @0x1d78
tl: 520 fb: -----L-- lb: 0x0  cc: 255
......
tab 0, row 13, @0x568
tl: 346 fb: --H-F--- lb: 0x1  cc: 79
nrid:  0x018083f8.c
col  0: [ 5]  c4 04 5a 3a 0a
col  1: [ 7]  47 59 30 32 30 30 31
col  2: [ 4]  c3 15 11 04
......
col 76: [ 1]  80
col 77: [ 1]  80
col 78: [ 1]  80
end_of_block_dump
End dump data blocks tsn: 6 file#: 6 minblk 33784 maxblk 33784

我們可以看到這裡對應的記錄根本就沒有。因為該block最後一條記錄是row 13，也就是第14行，也是一個row piece，而且存在一個nrid。
該nrid是0x018083f8.c，這表示該block 33784第12行記錄。跟row 13是組合成一條完整行記錄的。
換句話說，我們前面報錯的那條記錄，應該有2個row piece，其中一個row piece 是存在的，其中一個row piece 本應該存在在33784 block中。
但是由於找不到該row piece，因此oracle報了上述的錯誤。
實際上該錯誤遇到之後，我們通常以為是index的問題，通過drop 重建可以解決，然而這裡的問題比較特殊，據說是表的資料有問題。

所以這就是為什麼客戶重建index會報錯的原因：

SQL> CREATE INDEX "STATS"."MONTHINDEX_STATUS2" ON "STATS"."T_REPORT_MONTH" ("TARGET_298", "UNIT_LEVEL", "TARGET_VAL", "MONTH_FLG")
  2    TABLESPACE "STATDATA" ;
CREATE INDEX "STATS"."MONTHINDEX_STATUS2" ON "STATS"."T_REPORT_MONTH" ("TARGET_298", "UNIT_LEVEL", "TARGET_VAL", "MONTH_FLG")
                                                     *
第 1 行出現錯誤:

ORA-00600: 內部錯誤碼, 參數: [kdsgrp1], [], [], [], [], [], [], []
最後，我們清楚了所有原因，那麼要解決該問題很簡單。通過rowid的方式跳過這行有問題的記錄，將其他資料取出，重建表即可