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

而檢查此時的alert log可以發現有如下類似的錯誤：

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

1、expdp的寫程序報錯，因為日誌產生是dw程序。

2、dw程序報錯的原因是遭遇了ora-07445 [klufprd()+321]錯誤。

3、對於[klufprd()+321] 這個函式，非常少見。但是從前面2點我們可以知道這肯定與buffer cache有關係。
所以要臨時解決這個問題也很簡單。通過alter system flush buffer_cache 重新整理快取之後，再次進行expdp操作.
後續客戶嘗試了之後，發現expdp 操作雖然仍然會報錯，但是expdp 不會異常終止，會繼續完成後面其他物件的匯出。

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

很明顯，這裡提到這個這個表，恰好就是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。 如下是轉換的指令碼: