環境介紹：某資料倉儲，資料大小約40Tb，exdata,linux ,oracle 11.2.0.4 rac 資料版本
問題描述：上週五完成從生產rman恢復到該環境，週三客戶應用人員反映執行批處理時提示錯誤，錯誤日誌如下：

ERROR at line 1:
ORA-12801:error signaled in parallel query server P073,instance
edw3db01***************************
ORA-01578：ORACLE data block corrupted (file# 29,block # 23563007)
ORA-27616:ASM Allocation Unit:175144
ORA-01110:data file 29: '+DATA_EDW3/edw/datafile/tbs_iml_h.416.3333221113';

而錯誤的報錯點是一條insert 語句： INSERT /*append */ INTO VT_CM_PT_CORP_CUST_PFMC_03 nologging * 。
查詢alert 日誌，發現從週日開始就開始報ORA-01578錯誤，統計了一下，該錯誤一共被觸發了好幾十次，所有的錯誤都在提示在29號資料檔案上，而該檔案是bigfile ，大小約2.8T左右。這下不好玩了。

問題解決過程：
上午接近下班，客戶丟來問題，由於沒怎麼處理過這樣的問題，我只能先進行檢視，中午主要對alert 日誌，壞塊的物件進行檢視，
客戶說，可以打電話給oracle 400,於是下午打了oracle 400,那邊的工程師回了幾封郵件，丟來了一大堆要採集的資訊，一整下午反而浪費時間在收集資訊上了，唉，人家的服務流程我們也不好評價。
剛好下午有另個負責其他的oracle 原廠工程師在現場，但那位工程師處理這樣案例的經驗應該不多，建議使用 rman 的recoverblock 進行恢復，但此方法不生效。
現在詳述過程：
14：38分
將錯誤問題發給oracle 服務郵箱，並致電400服務電話，簡單與那邊工程師描述，那邊反饋需要採集資訊，詳細郵郵件回覆。

大約20分鐘之後
郵件回覆，於是根據其採集相關資訊，其中主要是 1.dbv 2.rman backup check validate 3.analyze table 4.exdata cell 兩個節點相關資訊，（因為在郵件中我也將 ora-27603，ora-27626 exdata 相關io錯誤也描述了） 5.資料庫節點主機資訊等 6.alert 日誌中報錯生成的trace 檔案。

以上做dbv 是一直得到的結果都是0，後來花時間測試一個小點的檔案，可以得到結果，難道是因為該資料檔案太大無法dbv？
做完以上回郵件大約花費了一個小時。

16：00左右
以上提到的  在現場的oracle 原廠工程師一堆查，都一直未動手。

16：20左右
準備使用list failure，advise failure; repair failure; 進行修復，卻在list failure 時提示了該操作無法在RAC下使用，於是放棄這種方法。

17：00左右
ORACLE原廠工程師，說可以使用 recoverblock 進行恢復，但最好是等400電話的工程師確認，但400那邊的工程師一直未給出建議，於是就直接採用該方法了。

set linesize 200
select * from v$database_block_corruption;
rman target /
run{
allocate channel d1 type disk;
backup check logical validate datafile 29;
release channel d1;
};
select * from v$database_block_corruption;

檢測出了 478處壞塊。。
選擇一個塊進行recoverblock

rman target /
RMAN> blockrecover datafile 29 block 23563007;

set linesize 100;
set pagesize 9999;
col owner for a10;
col segment_name for a30;
col segment_type for a15;
col tablespace_name for a20;
alter session force parallel query parallel 32;
select owner,segment_name,segemnt_type,tablespace_name from dba_extents where file_id=29 and 23563007 between block_id and block_id+blocks-1;
analyze table IML.XXXXXX validate structure;

對錶進行alalyze 時仍提示ora-01578錯誤，而且損壞的塊號仍是 23563007 ；

rman 下使用 blockrecover corruption list 進行全部恢復，不到一秒結束，只提示使用介質恢復，仍然無法修復。此時花了一段時間，在查rman 為何無法呼叫備份集，難道是之前使用了catelog start wit導致的？
後來這種方法也放棄了。

現場的oracle 原廠工程師因今天過來因為是負責其他事的，臨時被我們拉過來處理的，現在著急著走，值得尊重的是，他走了又折返還是不放心這邊，但最後走了仍未解決問題。400電話那邊oracle 工程師仍未回覆便不了了之。

直到晚上8：00，想到了另一種方法就是先設定事件SQL> alter system set events='10231 trace name context forever,level 10'; 使用資料泵跳過壞塊將相關的表匯出，之後刪除表再導回去，這樣的問題就是可能會丟失一些資料，由於現在還只是演練環境，所以丟失也沒辦法，將此方法發郵件回覆應用人員，準備第二天再看，但那邊催得緊，回覆是否可以從生產。我們回覆可以，便決定從生產匯出表再匯入。

此時我已經準備指令碼查詢478個壞塊相對應的物件，只是查詢

select owner,segment_name,segemnt_type,tablespace_name from dba_extents where file_id=29 and 23563007 between block_id and block_id+blocks-1;

非常慢，於是採用 create table as select ****重建一個表，建上索引，很快就將結果查出了。
一共是 73個表有壞塊。

查詢完，晚上九點多，便去吃晚飯，其間是各種電話以及牢騷，當然電話是打給客戶的。

大約22：00
便開始整理資料泵匯出指令碼，這七十三張表還好只有 200多GB。

整理完約23：00,便到生產環境操作區進行匯出，這裡的生產主機和演練主機都掛著同一個NFS，匯出是一個相對順利的過程，由於資料量也不多，大約不大一個小時便匯出了一部分表（我們是分每20張表分開匯出）。

凌晨12：00之後便開始實施匯入工作，其間比較不順利的是匯入時一直提示 ORA-39002: invalid operation
ORA-39070: Unable to open the log file. 錯誤，此時發現演練主機這邊的該NFS無論怎麼授權都只有 read-only許可權，即使匯入時去掉logfile項也同樣提示該問題，於是果斷將 dmp檔案複製到本地檔案系統，擴充了本地檔案系統空間開始進行匯入，直到凌晨4點多，資料泵匯入差基本完成。對其中已匯入的表做analyze，可以正常分析，  再做壞塊檢測，便先去睡覺了。

早上6點多，查詢檢測結果，發現仍然是478處壞塊，但根據壞塊去查物件時，並未查到物件，就是說原來的壞塊仍然存在，只是現在是空的資料塊。我擔心是我未將表刪除乾淨，於是清空回收站 purge dba_recyclebin;再次跑了檢測指令碼。此時已經非常疲憊，已經能確保不影響明天的業務了，便無心無力做其他操作，便回去大睡一天。

後記：此次產生這邊多壞塊可能是應 nologging操作引起。因為是資料倉儲，開發人員習慣性在操作都加上nologging以防止產生太多歸檔。

親歷資料倉儲ORA-01578:ORACLE data block corrupted錯誤的處理過程

相關文章