oracle壞塊修復

1、Oracle 壞塊 總結 收藏 Oracle數(shù)據(jù)庫出現(xiàn)壞塊現(xiàn)象是指：在Oracle數(shù)據(jù)庫的一個或多個數(shù)據(jù)塊（一個數(shù)據(jù)塊的容量在創(chuàng)建數(shù)據(jù)庫時由db_block_size參數(shù)指定，缺省為8K）內(nèi)出現(xiàn)內(nèi)容混亂的現(xiàn)象。由于正常的數(shù)據(jù)塊都有固定的合法內(nèi)容格式，壞塊的出現(xiàn)，導致數(shù)據(jù)庫進程無法正常解析數(shù)據(jù)塊的內(nèi)容，進而使數(shù)據(jù)庫進程報錯乃至掛起，并級聯(lián)導致整個數(shù)據(jù)庫實例出現(xiàn)異常。 一壞塊的產(chǎn)生原因 壞塊產(chǎn)生的原因大致有以下幾種：1.1 硬件問題Oracle進程在處理一個數(shù)據(jù)塊時，首先將其讀入物理內(nèi)存空間，在處理完成后，再由特定進程將其寫回磁盤；如果在這個過程中，出現(xiàn)內(nèi)存故障，CPU計算失誤，都會導致內(nèi)存數(shù)據(jù)塊

2、的內(nèi)容混亂，最后反映到寫回磁盤的數(shù)據(jù)塊內(nèi)容有誤。同樣，如果存儲子系統(tǒng)出現(xiàn)異常，數(shù)據(jù)塊損壞也就隨之出現(xiàn)了。 1.2 操作系統(tǒng)BUG由于Oracle進程對數(shù)據(jù)塊的讀寫，都是以操作系統(tǒng)內(nèi)核調(diào)用（system call）的方式完成的，如果操作系統(tǒng)在內(nèi)核調(diào)用存在問題，必然導致Oracle進程寫入非法的內(nèi)容。 1.3 操作系統(tǒng)的I/O錯誤或緩沖問題 1.4 內(nèi)存或paging問題 Oracle軟件BUGOracle軟件特定版本上，可能出現(xiàn)導致數(shù)據(jù)塊的內(nèi)容出現(xiàn)異常BUG。 1.5 非Oracle進程擾亂Oracle共享內(nèi)存區(qū)域如上文所述，在當數(shù)據(jù)塊的內(nèi)容被讀入主機的物理內(nèi)存時，如果其他非Oracle進程，對

3、Oracle使用的共享內(nèi)存區(qū)域形成了擾亂，最終導致寫回磁盤的數(shù)據(jù)塊內(nèi)容混亂。 1.6 異常關機，掉電，終止服務異常關機，掉電，終止服務使進程異常終止，而破壞數(shù)據(jù)塊的完整性，導致壞塊產(chǎn)生。注：這也是為什么突然斷電會導致數(shù)據(jù)庫無法啟動 由上可見，壞塊的形成原因復雜。當出現(xiàn)壞塊時，為了找到確切的原因，需要大量的分析時間和排查操作，甚至需要多次重現(xiàn)才能找出根本原因。但當故障發(fā)生在生產(chǎn)系統(tǒng)上，我們?yōu)榱藴p少停機時間，會盡快實施應急權變措施以保證系統(tǒng)的可用性，這樣就破壞了故障現(xiàn)場，對根本原因的分析因而也更加困難了。 二壞塊的預防 壞塊問題破壞性大，但并非不可預防。 “已知問題(known issues)說明

4、”。對于可能導致壞塊的Oracle軟件BUG，在Oracle公司內(nèi)部，是作為高嚴重級別的問題進行處理，在“已知問題(known issues)說明”中，這些BUG以嚴重（Noticable）問題標出(標記為*或+)，部分問題，Oracle還會發(fā)布警告(Alert)通告。在文檔中，Oracle會提供相應的補丁或應對措施。 2.2 Oracle提供備份恢復工具Recovery Manager，提供了掃描文件檢查壞塊的功能。在Recovery Manager界面中，使用： RMAN BACKUP CHECK LOGICAL VALIDATE DATAFILE n ; 可以檢查數(shù)據(jù)文件是否包含壞塊，同

5、時并不產(chǎn)生實際的備份輸出。 2.3 Dbv工具檢查注：因為dbv要求file后面跟的必須是一個文件擴展名，所以如果用裸設備存儲的，就必須使用ln鏈接裸設備到一個文件，然后再用dbv對這個鏈接文件進行檢查。 ANALYZE TABLE tablename VALIDATE STRUCTURE CASCADE它執(zhí)行壞塊的檢查，但是不會標記壞塊為corrupt，檢測的結果保存在USER_DUMP_DEST目錄下的用戶trace文件中。 2.4 利用exp工具導出整個數(shù)據(jù)庫可以檢測壞塊對以下情況的壞塊是檢測不出來的： HWM以上的壞塊是不會發(fā)現(xiàn)的 索引中存在的壞塊是不會發(fā)現(xiàn)的 數(shù)據(jù)字典中的壞塊是不會發(fā)

6、現(xiàn)的 結合數(shù)據(jù)庫性能綜合考慮db_block_checksum和db_blockchecking參數(shù)。 當我們使用Recovery Manager進行實際的數(shù)據(jù)庫備份時，同時也就進行了壞塊檢查。但要注意的是，在線使用Recovery Manager掃描壞塊和備份時，需要數(shù)據(jù)庫運行在歸檔模式（archive log），否則只能在數(shù)據(jù)庫未打開的情況下進行。 對于操作系統(tǒng)問題和硬件故障，則需要相應廠商的配合支持。同時，避免在數(shù)據(jù)庫主機運行其他用戶進程，避免異常停機，也會減少壞塊發(fā)生的幾率。 三壞塊故障的識別遇到壞塊問題時，數(shù)據(jù)庫的異常表現(xiàn)通常有：報告ORA-01578錯誤。報告Ora-1110錯誤。

7、報告ORA-00600錯誤，其中，第一個參數(shù)為2000-8000，Cache layer 2000 4000，Transaction layer 4000 6000，Data layer 6000 - 8000。Trace文件中出現(xiàn)Corrupt block dba: 0x160c5958 . found。分析對象失敗。后臺進程,如DBWR，LGWR出現(xiàn)長時間異常等待，如“LGWR wait for redo copy”。 四Oracle數(shù)據(jù)塊損壞恢復總結 可以用DBV 命令來檢測是否有壞塊： 在恢復前使用DBV命令檢查數(shù)據(jù)文件是否存在壞塊dbv file=d:oracleoradatamyd

8、bRONLY.DBF blocksize=8192 查看數(shù)據(jù)壞塊所在數(shù)據(jù)文件號及塊號可以對表進行一次全表掃描，如：select count(*) from tablename; 關于DBV 命令的具體使用，請參考blog： 4.1 沒有備份的情況下：在這種情況下肯定會造成數(shù)據(jù)的丟失，在這種情況下應采取將數(shù)據(jù)導出然后重建表再進行導入的方法，來盡量恢復損壞數(shù)據(jù)塊中的數(shù)據(jù)，但是在有壞塊的情況下是不允許導出的，如下命令：Exp test/test file=t.dmp tables=t; 導出命令在執(zhí)行中會報ORA-01578錯誤，在這錯誤提示中會提示那個文件號的文件以及這個文件中的哪個塊被損壞，如：

9、ORA01578：ORACLE 數(shù)據(jù)塊損壞（文件號 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; 如果被損壞的塊是索引，通常可以通過索引重建來解決，如果損壞的是數(shù)據(jù)（segment_type為table），那么通過設置如下內(nèi)部事件使得Exp操作跳過壞塊。Alter session set events=10231 tr

10、ace name context forever,level 10; 然后重新執(zhí)行導出命令，導出相關的表，然后執(zhí)行Drop Table命令刪除相關表，之后重建表最后導入數(shù)據(jù)。 用DBMS_REPAIR當然也會丟失數(shù)據(jù)。這里不做詳細的介紹，有興趣的可以查看oracle的在線文檔 4.2 使用Rman進行恢復：首先要存在Rman的最新備份集，然后執(zhí)行如下命令：RMANbackup validate datafile 4; 檢查4號數(shù)據(jù)文件是否存在壞塊執(zhí)行查詢：select * from v$database_block_corruption where file#=4; 如果4號文件存在壞塊的話，

11、那么將在結果集中有所顯示，會顯示損壞的塊號，根據(jù)顯示結果執(zhí)行如下命令進行恢復：RMANblockrecover datafile 4 block 35 from backupset; 該命令執(zhí)行后即可恢復壞塊，并且不會造成數(shù)據(jù)丟失，但是要求數(shù)據(jù)庫必須要運行在歸檔模式下，否則RMAN無法發(fā)揮作用，而且通過RMAN做過最新的數(shù)據(jù)庫備份 4.3 使用bbed恢復使用bbed恢復時必須有數(shù)據(jù)文件的拷貝。bbed就是英文block browse edit的縮寫，用來直接查看和修改數(shù)據(jù)文件數(shù)據(jù)的一個工具。 BBED在windows 8i中在$ORACLE_HOME/bin下可以找到，9i中似乎未隨軟件發(fā)布

12、，故在windows沒有這個工具，linux下需要編譯：然后把$ORACLE_HOME/rdbms/lib加到環(huán)境變量的PATH里面，就可以直接在命令中bbed了。BBED的缺省口令為blockedit,For Oracle Internal Use only 請謹慎使用Oracle不做技術支持。 BBED具體的使用，參考blog： 五如何查找壞塊所含的數(shù)據(jù)表名稱和數(shù)據(jù)的rowid關于Rowid 的相關知識參看blog： 5.1. 首先肯定知道那個數(shù)據(jù)文件壞了，查出該文件的file_id,relative_fno,tablespace_name 利用dba_data_files可以查詢file

13、_id(整個數(shù)據(jù)庫唯一序號),RELATIVE_FNO(相對一個表空間內(nèi)的序號) 5.2. 找到壞塊的ID（可以運行dbverify實現(xiàn)），假設找到的壞塊ID為1234。segment_name等信息 select owner,file_id,segment_name, segment_type, block_id, blocksfrom dba_extentswhere file_id=13 and block_id= 1234; 5.4. 根據(jù)壞塊的file_id,owner,segment_name,block_id,如果是數(shù)據(jù)表的話，用下面的查詢來得到對應壞塊的rowid 假設owne

14、r : DAVE segment_name: BL file_id : 13 block_id : 162 運行下面的查詢來獲得該塊所含的rowid(如果沒有索引，可能就不能用下面的方式了): select /*+ index(DAVE, i_test)*/ rowid from DAVE.BL where dbms_rowid.rowid_to_absolute_fno(rowid,DAVE,BL)=13 and dbms_rowid.rowid_block_number(rowid)=162; 六，如何模擬壞塊 DBA 的基本知識，制造壞塊的方法很多的，可以用ultraedit,也可以用d

15、d命令，同時也呆以用orapatch工具 6.1 orapatch 工具：$orapatch open tools001.dbf writepatchset hex -要用十六進制patchdisplay 177 -orapatch以512字節(jié)為工作模式，假定想破壞第11個block即為：8k/512*11+1(file header)patchfind 00400003 -選一個要編輯的點patchmodify 00400002 -破壞patchexit 6.2 用編輯器打開 datafile 以 8192 字節(jié)為一大小(db 的block是 8192)下面是一個 block 的開始的 20

16、個字節(jié)和結尾的 4 個字節(jié)06 02 00 00 08 00 c0 02 6c 43 0d 00 00 00 01 0200 00 00 00 - block head06 02 6c 43 - block tail 這里有 scn(6c 43) 的情況和 block (06)的類型 (01) 和 head 的 seq: 0x01 對應，只要改block尾部的4個字節(jié)中的或block開始的對應字節(jié)任何一個就一定會有 ora-1578，但如果數(shù)據(jù)庫有 ora-1578的 error不一定是這樣引起的btw ： UE不是很好 用winhex吧 不錯喔 6.3 BBED 工具 BBED具體的使用，參

17、考blog： 七 如何利用dbms_repair來標記和跳過壞塊但是當數(shù)據(jù)量很大，或7*24的系統(tǒng)時，我們使用dbms_repair來處理。dbms_repair是從oracle8i開始提供的。 準備工作：create tablespace block datafile /u01/block.dbf size 5M; create table DMM tablespace block as select * from all_tables; commit; CREATE INDEX indx_dmm on DMM(TABLE_NAME);select count(*) from DMM; CO

18、UNT(*)-12896 SQL conn sys/admin as sysdba;已連接。SQL exec DBMS_REPAIR.ADMIN_TABLES(REPAIR_TABLE,1,1,USERS);PL/SQL procedure successfully completedSQL exec DBMS_REPAIR.ADMIN_TABLES(ORPHAN_TABLE,2,1,USERS);PL/SQL procedure successfully completed Set serveroutput on;DECLARE cc NUMBER;BEGIN DBMS_REPAIR.che

19、ck_object (schema_name = SYS, - 注意此處是用戶名 object_name = DMM, corrupt_count = cc); DBMS_OUTPUT.put_line ( TO_CHAR (cc);END; 正常情況下輸入為0. 如果有壞塊，可以在創(chuàng)建的REPAIR_TABLE中查看塊損壞信息： SELECT object_name, relative_file_id, block_id, marked_corrupt, corrupt_description, repair_description, CHECK_TIMESTAMP FROM repair_

20、table; 注意：在8i下，check_object只會檢查壞塊，MARKED_CORRUPT為false，故需要執(zhí)行第三步： 定位壞塊，fix_corrupt_blocks定位 ，修改MARKED_CORRUPT為true，同時更新CHECK_TIMESTAMP。9i以后經(jīng)過check_object，MARKED_CORRUPT的值已經(jīng)標識為TRUE了。所以可以直接進行第四步了。 只有將壞塊信息寫入定義的REPAIR_TABLE后，才能定位壞塊。 DECLARE cc NUMBER;BEGIN DBMS_REPAIR.fix_corrupt_blocks (schema_name = SY

21、S, object_name = DMM, fix_count = cc); DBMS_OUTPUT.put_line (a = TO_CHAR (cc);END; 我們前面雖然定位了壞塊，但是，如果我們訪問table：SQL select count(*) from SYS.DMM; ORA-01578: ORACLE 數(shù)據(jù)塊損壞（文件號14，塊號154）ORA-01110: 數(shù)據(jù)文件 14: D: BLOCK.DBF 還是會得到錯誤信息。 這里需要用skip_corrupt_blocks來跳過壞塊： exec dbms_repair.skip_corrupt_blocks(schema_n

22、ame = SYS,object_name = DMM,flags = 1); SQL select count(*) from SYS.DMM; COUNT(*)- 12850丟失了128961285046行數(shù)據(jù)。 DECLARE cc NUMBER;BEGIN DBMS_REPAIR.dump_orphan_keys (schema_name = SYS, object_name = INDX_DMM, object_type = 2, repair_table_name = REPAIR_TABLE, orphan_table_name = ORPHAN_TABLE, key_count

23、 = CC);END; 通過以下命令可以知道丟失行的信息：SQL SELECT * FROM ORPHAN_TABLE; 我們根據(jù)這個結果來考慮是否需要rebuild index. exec dbms_repair.rebuild_freelists(schema_name = SYS,object_name = DMM); 八 設置內(nèi)部事件使exp跳過壞塊我們可以用設置event的方法來處理壞塊：先模擬出壞塊，然后用dbv檢查，此時，不用dbms_repair，而用下面的方法： 8.1. 先exp該表試驗一下在這種情況下，如果有備份，需要從備份中恢復，如果沒有備份，那么壞塊部分的數(shù)據(jù)肯定要丟失了在這個時候?qū)С鍪遣辉试S的:E:exp system/admin file=t.dmp tables=t報錯如下：即將導出指定的表通過常規(guī)路徑 . . 正在導出表 TEXP-00056: 遇到 ORACLE 錯誤 1578ORA-01578: ORACLE 數(shù)據(jù)塊損壞（文件號4，塊號35）ORA-01110: 數(shù)據(jù)文件 4: E:ORACLEORADATAEYGLEBLOCK.DBF導出成功終止，但出現(xiàn)警告。 8.2. 對于不同的情況需要區(qū)別對待 ，如果損失不是數(shù)據(jù)而是重要的oracle內(nèi)部信息，則不能用set event。 首先你需要檢