Oracle 壞塊處理三板斧

Oracle 壞塊處理三板斧

---

在ORACLE中形成 資料塊損壞/壞塊診斷corruption多種多樣，但其症狀大致為如下幾種：
ORA-01578錯誤
ORA-600[61xx]錯誤
ORA-600[3339]或者ORA-600[3398]
ORA-600[2130],ORA-600[2845],ORA-600[4147]錯誤等等
SELECT 查詢出訛誤的資料
 
應當該類ORACLE資料塊損壞/壞塊診斷的問題 有這麼幾個三板斧的步驟：
1、如果資料庫仍然是開啟狀態，則需要判斷該塊損壞/壞塊所在的 資料檔案號、塊號 並定位到具體的物件(可能是表或者索引)。 結合ORA-1578錯誤或者ORA-600報出的變數資訊，採取如下SQL來定位
 
SELECT tablespace_name, segment_type, owner, segment_name
FROM dba_extents
WHERE file_id = &fileid
and &blockid between block_id AND block_id + blocks - 1;
 
2、取決於上一步獲得的SEGMENT_TYPE， 如果是以下的SEGMENT_TYPE是可以重建的：
index
資料可以重新獲得的表，或者可以重建的表
回滾段，除了SYSTEM這個回滾段
排序段 , sort segment
臨時表
 
 
3、 如果不屬於步驟2中支出的任何一種，那麼需要注意以下的資訊：
資料庫是否是歸檔模式
有無表的備份資料，包括export /sqlldr
是否該表上有基於 NOT NULL欄位的索引？
如果有這樣的索引，那麼是否是UNIUQE的？
 
4、是否這套庫從前已經有塊損壞/壞塊的情況？ 這一點有經驗的DBA可以從alert.log大致瞭解情況的， 如果以往有過此類問題則可以參考下文的後續建議
 
5、如果使用者正使用歸檔模式，則應當建議儲存一份歸檔redo和線上日誌以便今後的後續診斷。如果不是，則要求使用者備份所有的線上日誌
 
6、在有條件的情況下做10210,10211和10212 event來捕捉錯誤源頭。 如果現場工程師懷疑問題不是由於 ORACLE本身引起的，則建議dump 有問題的資料塊並結合OS和儲存、卷管理器的日誌來分析。  如果懷疑是記憶體損壞則有必要考慮_db_block_cache_protect ，注意不是所有平臺支援_db_block_cache_protect而且其損壞較多效能
 
7、在某些情況下，有必要要求使用者啟用歸檔模式來避免後續再次發生問題時無法有效恢復
 
必要收集的證據
 
1、 包括ORACLE TRACE和ALERT檔案，這個是我們診斷此類問題的源頭， 並分析這些報告中是否有其他資料塊被報告存在損壞
2、從OS角度轉儲壞的資料塊
Unix: dd if=badfile.dbf count=5 bs=2048 skip=75
 
 
後續建議
 
1、當我們在分析trace或redo日誌轉儲時 有必要調整使用者的預期，要表達給使用者這些資訊：
我們在幫助判斷原因，而不是判斷如何修復這些壞塊
我們在研究這些證據，但這些證據未必能讓我們下決定性的結論
 
 
2、有時候資料塊是在記憶體中損壞了 例如ORA-600[3398]，為了驗證這些情況可以：
analyze table X validate structure cascade;
alter system flush buffer_cache;
從OS角度轉儲該資料塊並分析
 
 
後續措施
 
1、尋找本質， 例如：
所有的損壞都只發生在某個裸裝置或者裝置或者控制器上
每數4個塊出現一個壞塊
資料塊本身沒問題，但是出現的位置不對
資料塊的部分是健康的，但其他地方不正確
 
2、 透過繞過存在 損壞/壞塊的資料塊來重建表：
使用10231 level 10事件來執行一個全表掃描的CTAS
透過構建ROWID來避免訪問損壞的資料塊 【資料恢復】利用構造ROWID實現無備份情況下繞過ORA-1578、ORA-8103、ORA-1410等邏輯/物理壞塊問題
 
3、 啟用10210、10211和10212並更新資料塊來進一步定位壞塊的細節，並考慮使用10231 event
 
其他工具
 
其他可選的工具包括dul、oranum、orapatch、bbed等，這些都是ORACLE內部工具。
FILED UNDER: ORACLE, ORACLE資料恢復、資料庫恢復、災難恢復