ORACLE壞塊總結（轉）

Oracle資料庫出現壞塊現象是指：在Oracle資料庫的一個或多個資料塊（一個資料塊的容量在建立資料庫時由db_block_size引數指定，預設為8K）內出現內容混亂的現象。由於正常的資料塊都有固定的合法內容格式，壞塊的出現，導致資料庫程式無法正常解析資料塊的內容，進而使資料庫程式報錯乃至掛起，並級聯導致整個資料庫例項出現異常。

 

一．壞塊的產生原因

 

壞塊產生的原因大致有以下幾種：

1.1硬體問題

Oracle程式在處理一個資料塊時，首先將其讀入實體記憶體空間，在處理完成後，再由特定程式將其寫回磁碟；如果在這個過程中，出現記憶體故障，CPU計算失誤，都會導致記憶體資料塊的內容混亂，最後反映到寫回磁碟的資料塊內容有誤。同樣，如果儲存子系統出現異常，資料塊損壞也就隨之出現了。

 

1.2作業系統BUG

由於Oracle程式對資料塊的讀寫，都是以作業系統核心呼叫（system call）的方式完成的，如果作業系統在核心呼叫存在問題，必然導致Oracle程式寫入非法的內容。

 

1.3作業系統的I/O錯誤或緩衝問題

 

1.4記憶體或paging問題

 

Oracle軟體BUG

Oracle軟體特定版本上，可能出現導致資料塊的內容出現異常BUG。

 

1.5非Oracle程式擾亂Oracle共享記憶體區域

如上文所述，在當資料塊的內容被讀入主機的實體記憶體時，如果其他非Oracle程式，對Oracle使用的共享記憶體區域形成了擾亂，最終導致寫回磁碟的資料塊內容混亂。

 

1.6異常關機，掉電，終止服務

異常關機，掉電，終止服務使程式異常終止，而破壞資料塊的完整性，導致壞塊產生。

注：這也是為什麼突然斷電會導致資料庫無法啟動

 

由上可見，壞塊的形成原因複雜。當出現壞塊時，為了找到確切的原因，需要大量的分析時間和排查操作，甚至需要多次重現才能找出根本原因。但當故障發生在生產系統上，我們為了減少停機時間，會盡快實施應急權變措施以保證系統的可用性，這樣就破壞了故障現場，對根本原因的分析因而也更加困難了。

 

二．壞塊的預防

 

壞塊問題破壞性大，但並非不可預防。

 

2.1在Metalink.oracle.com網站，Oracle定期釋出基於特定軟體版本的“已知問題(known issues)說明”。對於可能導致壞塊的Oracle軟體BUG，在Oracle公司內部，是作為高嚴重級別的問題進行處理，在“已知問題(known issues)說明”中，這些BUG以嚴重（Noticable）問題標出(標記為*或+)，部分問題，Oracle還會發布警告(Alert)通告。在文件中，Oracle會提供相應的補丁或應對措施。

 

2.2Oracle提供備份恢復工具－Recovery Manager，提供了掃描檔案檢查壞塊的功能。

在Recovery Manager介面中，使用：

RMAN> BACKUP CHECK LOGICAL VALIDATE DATAFILE n ;

 

可以檢查資料檔案是否包含壞塊，同時並不產生實際的備份輸出。

 

2.3Dbv工具檢查

注：因為dbv要求file後面跟的必須是一個副檔名，所以如果用裸裝置儲存

的，就必須使用ln連結裸裝置到一個檔案，然後再用dbv對這個連結檔案進行檢

查。

 

ANALYZE TABLE tablename VALIDATE STRUCTURE CASCADE

它執行壞塊的檢查，但是不會標記壞塊為corrupt，檢測的結果儲存在USER_DUMP_DEST目錄下的使用者trace檔案中。

 

2.4利用exp工具匯出整個資料庫可以檢測壞塊

對以下情況的壞塊是檢測不出來的：

 HWM以上的壞塊是不會發現的

 索引中存在的壞塊是不會發現的

 資料字典中的壞塊是不會發現的

 

結合資料庫效能綜合考慮db_block_checksum和db_blockchecking引數。

 

當我們使用Recovery Manager進行實際的資料庫備份時，同時也就進行了壞塊

檢查。但要注意的是，線上使用Recovery Manager掃描壞塊和備份時，需要數

據庫執行在歸檔模式（archive log），否則只能在資料庫未開啟的情況下進行。

 

對於作業系統問題和硬體故障，則需要相應廠商的配合支援。同時，避免在數

據庫主機執行其他使用者程式，避免異常停機，也會減少壞塊發生的機率。

 

三．壞塊故障的識別

遇到壞塊問題時，資料庫的異常表現通常有：

報告ORA-01578錯誤。

報告Ora-1110錯誤。

報告ORA-00600錯誤，其中，第一個引數為2000-8000，Cache layer 2000 – 4000，Transaction layer 4000 – 6000，Data layer 6000 - 8000。

Trace檔案中出現Corrupt block dba: 0x160c5958 . found。

分析物件失敗。

後臺程式,如DBWR，LGWR出現長時間異常等待，如“LGWR wait for redo copy”。

 

 

四．Oracle資料塊損壞恢復總結

 

可以用DBV命令來檢測是否有壞塊：

 

在恢復前使用DBV命令檢查資料檔案是否存在壞塊

dbv file=d:\oracle\oradata\mydb\RONLY.DBF blocksize=8192

 

檢視資料壞塊所在資料檔案號及塊號可以對錶進行一次全表掃描，如：

select count(*) from tablename;

 

 

 

4.1沒有備份的情況下：

4.1.1、使用exp/imp恢復

在這種情況下肯定會造成資料的丟失，在這種情況下應採取將資料匯出然後重建表再進行匯入的方法，來儘量恢復損壞資料塊中的資料，但是在有壞塊的情況下是不允許匯出的，如下命令：

Exp test/test file=t.dmp tables=t;

 

匯出命令在執行中會報ORA-01578錯誤，在這錯誤提示中會提示那個檔案號的檔案以及這個檔案中的哪個塊被損壞，如：ORA—01578：ORACLE資料塊損壞（檔案號4，塊號35）

針對以上的提示首先查詢那些物件被損壞：

 

Select tablespace_name,segment_type,owner,segment_name From dba_extents Where file_id=4 and 35 between block_id and block_id+blocks-1;

 

如果被損壞的塊是索引，通常可以通過索引重建來解決，如果損壞的是資料（segment_type為table），那麼通過設定如下內部事件使得Exp操作跳過壞塊。

Alter session set events=’10231 trace name context forever,level 10’;

 

然後重新執行匯出命令，匯出相關的表，然後執行Drop Table命令刪除相關表，之後重建表最後匯入資料。

 

4.1.2、使用DBMS_REPAIR恢復

用DBMS_REPAIR當然也會丟失資料。這裡不做詳細的介紹，有興趣的可以檢視oracle的線上文件

 

 

4.2使用Rman進行恢復：

首先要存在Rman的最新備份集，然後執行如下命令：

RMAN>backup validate datafile 4;

 

檢查4號資料檔案是否存在壞塊

執行查詢：

select * from v$database_block_corruption where file#=4;

 

如果4號檔案存在壞塊的話，那麼將在結果集中有所顯示，會顯示損壞的塊號，根據顯示結果執行如下命令進行恢復：

RMAN>blockrecover datafile 4 block 35 from backupset;

 

該命令執行後即可恢復壞塊，並且不會造成資料丟失，但是要求資料庫必須要執行在歸檔模式下，否則RMAN無法發揮作用，而且通過RMAN做過最新的資料庫備份

 

 

4.3使用bbed恢復

使用bbed恢復時必須有資料檔案的拷貝。

bbed就是英文block browse edit的縮寫，用來直接檢視和修改資料檔案資料的一個工具。

 

BBED在windows 8i中在$ORACLE_HOME/bin下可以找到，9i中似乎未隨軟體釋出，故

在windows沒有這個工具，linux下需要編譯：

然後把$ORACLE_HOME/rdbms/lib加到環境變數的PATH裡面，就可以直接在命令中bbed了。

BBED的預設口令為blockedit,

For Oracle Internal Use only請謹慎使用Oracle不做技術支援。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/758322/viewspace-688765/，如需轉載，請註明出處，否則將追究法律責任。