oracle壞塊(二)

壞塊故障的恢復

完整的備份恢復策略是恢復壞塊最有效的方法。備份恢復策略至少應該包括定期的資料庫物理備份和日誌歸檔。其中，歸檔日誌還可以作為判別壞塊產生原因的工具。

1、當出現壞塊時，使用物理備份進行檔案還原，在此檔案基礎上使用歸檔日誌恢復至故障時間點。以Recovery Manager為例：

1) 先offline受影響的資料檔案，執行以下的語句：

 

ALTER DATABASE DATAFILE 'name_file' OFFLINE；

 

2) 保留有壞塊的資料檔案，然後拷貝備份的資料檔案。如果恢復的資料檔案要求路徑

不同，執行以下的語句：

 

ALTER DATABASE RENAME FILE 'old_name' TO 'new_name';

 

3) 恢復資料檔案，執行以下語句：

 

RECOVER DATAFILE 'name_of_file';

 

4) Online恢復後的資料檔案，執行以下的語句：

 

ALTER DATABASE DATAFILE 'name_of_file' ONLINE;

 

2、在特定情況下(9i以上版本可用)，還可以使用塊級恢復，以加快恢復程式：

RMAN> blockrecover datafile n block nnnn;

 

3、通過ROWID RANGE SCAN 儲存資料

 

1) 先取得壞塊中ROW ID的最小值，執行以下的語句：

 

SELECT dbms_rowid.rowid_create(1,,,,0) from

DUAL;

 

2）取得壞塊中的ROW ID的最大值，執行以下的語句：

 

SELECT dbms_rowid.rowid_create(1,,,+1,0) from

DUAL;

 

3）建議一個臨時表儲存那些沒有壞塊的資料，執行以下的語句：

 

CREATE TABLE salvage_table AS SELECT * FROM corrupt_tab Where 1=2;

 

4）儲存那些不存在壞塊的資料到臨時表中，執行以下的語句：

 

INSERT INTO salvage_table SELECT /*+ ROWID(A) */ * FROM

  A WHERE rowid < ''；

 

INSERT INTO salvage_table SELECT /*+ ROWID(A) */ * FROM

A WHERE rowid >= '‘;

 

5) 根據臨時表中的資料重建表，重建表上的索引，限制。

 

4、使用10231診斷事件，在做全表掃描的時候跳過壞塊

 

可以在session級別設定：

 

ALTER SESSION SET EVENTS '10231 TRACE NAME CONTEXT FOREVER,

 LEVEL 10';

 

也可以在資料庫級別上設定，在初始化引數中加入：event="10231 trace name

context forever, level 10" ，然後重啟資料庫。

 

然後從存在壞塊的表中取出不存在壞塊的資料，執行以下的語句：

 

CREATE TABLE salvage_emp AS SELECT * FROM corrupt_table;

 

最後rename生成的corrupt_table為原來表的名字，並重建表上的索引和限制。

 

5、使用dbms_repair包進行恢復

 

使用dbms_repair標記有壞塊的表，在做全表掃描的時候跳過壞塊，執行以下的

語句：

 

Execute

DBMS_REPAIR.SKIP_CORRUPT_BLOCKS('','');

 

然後使用exp工具或者createtable as select的方法取出沒有壞塊資料，然後

重建表，表上的索引和限制。

 

6、UNDO表空間壞塊

 

1)　dump undoheader（如果資料庫不能open用event 1015升成trace檔案，本案例的情況）找到活動事務（狀態為10）和對應的undo dba地址和使用的回滾段：

SQL> alter system dump undo header "_SYSSMU22$";

SQL> alter system dump undo header "_SYSSMU27$";

或者:

ALTER SYSTEM SET event="10015 trace name context forever, level 10"

SCOPE=SPFILE;

 

  index  state cflags  wrap#    uel         scn            dba 

parent-xid    nub 

   stmt_num

  ------------------------------------------------------------------------------------------------

   0x11   10    0x90  0x5a1a0  0x0007  0x000b.4a936c82  0x0140d7bf 

0x0000.000.00000000  0x00000001   0x00000000   0x0000

……

Recovering rollback segment _SYSSMU27$

Recovering rollback segment _SYSSMU22$

 

SQL> select dbms_utility.data_block_address_file(21026751) "file",

  2  dbms_utility.data_block_address_block(21026751) "block"

  3  from dual;

 

      file      block

---------- ----------

5                 55231

           

2)　dump回滾段內容得到相關活動事物對應的物件以便以後進行處理(也可以資料庫啟動後查詢系統表來判斷 select owner,segment_name from dba_segments where segment_name='PENDING_TRANS$';)：

 

SQL> alter system dump datafile 5 block 55231;

 

********************************************************************************

UNDO BLK: 

xid: 0x0016.010.0005a635  seq: 0x3696 cnt: 0x42  irb: 0x42  icl: 0x0   flg: 0x0000

 

*-----------------------------

* Rec #0x42  slt: 0x10  objn: 17674(0x0000450a)  objd: 17674  tblspc: 12(0x0000000c)

*       Layer:  10 (Index)   opc: 22   rci 0x41  

Undo type:  Regular undo   Last buffer split:  No

Temp Object:  No

Tablespace Undo:  No

rdba: 0x00000000

*-----------------------------

 

3)　設定隱含引數跳過相應回滾段：

_offline_rollback_segments= _SYSSMU22$, _SYSSMU27$

 

4) 啟動資料庫，刪除offline的回滾段並處理活動事物對應的物件：

drop rollback segemnt "_SYSSMU22$";

drop rollback segemnt "_SYSSMU27$";

處理活動事務相關的物件（rebuild index，exchange partition，drop

table）等。

 

在沒有完整備份恢復策略的情況下，可以使用應急手段進行恢復，但過程較為

複雜且風險較大。

 

完整備份恢復策略需要合理規劃和相應的資源投入。

 

總結

資料庫壞塊問題原因複雜，破壞性大。但完整的備份恢復策略，經常性的檢查，有效的故障識別以及對應的恢復手段，可以幫助使用者最大限度的應對資料庫壞塊問題所帶來的風險。

 

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