恢複資料塊壞塊

2014.7.22研究恢複資料庫壞塊：

Oracle調用标準C的系統函數，對資料塊進行讀寫操作，是以，壞塊是有可能由以下幾種原因産生：

硬體的I/O錯誤

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

記憶體或paging問題

磁盤修複工具

一個資料檔案的一部分正在被覆寫

Oracle試圖通路一個未被格式化的系統塊失敗

資料檔案部分溢出

Oracle或者作業系統的bug

遇到“ORA-01578:ORACLE data block corrupted”錯誤

處理方法：1.rman的recover指令可以在資料庫保持open狀态下隻恢複受損的資料塊

        2.如果沒有備份，萬不得已之下也可以采用DBMS_REPAIR包的存儲過程将受損壞塊隔離，同時盡可能地挽救部分資料。

rman backup指令也是檢查壞資料塊的好工具  一旦讀取ORA-19566  即可有問題

此時可用backup validate tablespace user觀察詳細的資訊，可檢視到壞塊數與跟蹤檔案

grep‘corrupt’/u01/app/oracle/diag/rdbms/br/br/trace/**.trc

恢複資料塊：rman》recover datafile 5 block 203；

批量恢複受損的資料塊：recover corruption list;

資料塊壞塊一号壞塊，需要做：

run{

sql 'alter database datafile 5 offline';

 restore datafile 5;

 recover datafile 5;

sql'alter database datafile 5 online'

}

使用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指令删除相關表，之後重建表最後導入資料。

使用DBMS_REPAIR恢複

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

3、使用dbms_repair包進行壞塊處理

1）首先建立repair_table,用于存放dbms_repair.check_object檢測出來的壞塊資訊

SQL> declare

2begin

3dbms_repair.admin_tables

4(table_name => 'REPAIR_TABLE',--表名

5table_type => dbms_repair.repair_table,

6action => dbms_repair.create_action,

7tablespace => 'USERS');--用于指定該表存放的表空間

8end;

9/

PL/SQL 過程已成功完成。

SQL> col owner format a10

SQL> col object_name format a20

SQL> col object_type format a20

SQL> select owner, object_name, object_type

2from dba_objects

3where object_name like '%REPAIR_TABLE';

OWNEROBJECT_NAMEOBJECT_TYPE

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

SYSREPAIR_TABLETABLE

SYSDBA_REPAIR_TABLEVIEW

Oracle自動建立了一個DBA_REPAIR_TABLE視圖。

2）使用dbms_repair.check_object進行壞塊檢測

SQL> set serveroutput on size 100000;

2rpr_count int;

3begin

4rpr_count := 0;

5dbms_repair.check_object(

6schema_name => 'SYS',--指定對象模式，也就是對象的所有者

7object_name => 'TEST',--指定對象名，也就是表名

8repair_table_name => 'REPAIR_TABLE',

9corrupt_count => rpr_count);

10dbms_output.put_line('repair block count: '

11||to_char(rpr_count));

12end;

13/

repair block count: 4

SQL> select object_name, block_id, corrupt_type, marked_corrupt,

2corrupt_description, repair_description

3from repair_table;

OBJECT_NAMEBLOCK_ID CORRUPT_TYPE MARKED_COR

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

CORRUPT_DESCRIPTION

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

REPAIR_DESCRIPTION

TEST196148 TRUE

mark block software corrupt

TEST206148 TRUE

TEST236148 TRUE

TEST316148 TRUE

通過運作dbms_repair.check_object，将壞塊資訊存放到了repair_table表中，其中有個字段marked_corrupt，用于辨別該塊是否被辨別為壞塊，當被辨別為true時，即該塊被辨別為壞塊。其中這一步跟oracle文檔中的描述有點進入，根據oracle文檔，當執行完dbms_repair.check_object時，并不會進行壞塊辨別，也就是marked_corrupt列的值應該為false，而隻有當執行dbms_repair.fix_corrupt_blocks過程後才會進行壞塊辨別。

3）使用dbms_repair.fix_corrupt_blocks進行壞塊辨別

2fix_block_count int;

4fix_block_count := 0;

5dbms_repair.fix_corrupt_blocks (

6schema_name => 'SYS',

7object_name => 'TEST',

8object_type => dbms_repair.table_object,

9repair_table_name => 'REPAIR_TABLE',

10fix_count => fix_block_count);

11dbms_output.put_line('fix blocks count: ' ||

12to_char(fix_block_count));

13end;

14/

fix blocks count: 0

我們可以見到到fix blocks count=0，即在上一步進行check_object時已經進行了壞塊辨別了，這一步其實可以省略。（不過沒有測試過！）

SQL> select count(*) from test;

select count(*) from test

*

第 1 行出現錯誤:

ORA-01578: ORACLE 資料塊損壞 (檔案号 7, 塊号 19)

ORA-01110: 資料檔案 7: 'G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\TEST01.DBF'

此時進行查詢仍然報錯，因為我們隻是将壞塊進行了辨別，當進行全表掃描的時候，仍然會查詢到壞塊而報錯。

4）使用dbms_repair.dump_orphan_keys過程來儲存壞塊的索引鍵值，然後再執行skip_corrupt_blocks過程之後，我們才能重建索引，不然重建索引時新的索引仍然會引用壞塊。首先要建立ORPHAN_KEY_TABLE，此表就是用來存放壞塊的索引鍵值。

4(table_name => 'ORPHAN_KEY_TABLE',

5table_type => dbms_repair.orphan_table,

7tablespace => 'USERS');

然後執行過程dbms_repair.dump_orphan_keys将壞塊鍵值存放到上面所建立的表中：

2orph_count int;

4orph_count:= 0;

5dbms_repair.dump_orphan_keys (

7object_name => 'ID_INX',--索引的名字

8object_type => dbms_repair.index_object,

9repair_table_name => 'REPAIR_TABLE',--從這個表中獲得壞塊的資訊

10orphan_table_name => 'ORPHAN_KEY_TABLE',

11key_count => orph_count);

12dbms_output.put_line('orphan-index entries: ' || to_char(orph_count));

orphan-index entries: 491

7object_name => 'NAME_INX',

對每個索引都要進行dump_orphan_keys。

SQL> select index_name, count(*) from orphan_key_table

2group by index_name;

INDEX_NAMECOUNT(*)

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

ID_INX491

NAME_INX491

5）使用skip_corrupt_blocks，使查詢或者DML時跳過壞塊

3dbms_repair.skip_corrupt_blocks (

4schema_name => 'SYS',

5object_name => 'TEST',

6object_type => dbms_repair.table_object,

7flags => dbms_repair.skip_flag);

SQL> select table_name, skip_corrupt from dba_tables

2where table_name = 'TEST';

TABLE_NAMESKIP_COR

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

TESTENABLED

6）使用dbms_repair.rebuild_freelists重建freelists，使得該塊不再被放到freelists，當中，也就是該塊将不會再被使用。

3dbms_repair.rebuild_freelists (

6object_type => dbms_repair.table_object);

7end;

8/

declare

ORA-10614: Operation not allowed on this segment

ORA-06512: 在 "SYS.DBMS_REPAIR", line 400

ORA-06512: 在 line 3

不過我們可以看到，對于SYS使用者下面的對象好像不能進行此操作。

4、重建索引

SQL> select count(id) from test;

COUNT(ID)

----------

19998

SQL> select count(name) from test;

COUNT(NAME)

-----------

COUNT(*)

19507

我們可以看到上面的三個查詢，對于第1和第2個使用索引進行查詢和不使用索引進行查詢的結果是不一樣的。下面我們使用rebuild試試。

SQL> alter index id_inx rebuild;

索引已更改。

SQL> alter index name_inx rebuild;

可以是不能通過rebuild來重建索引的。隻能通過DROP然後再CREATE。

SQL> drop index id_inx;

索引已删除。

SQL> drop index name_inx;

SQL> create index id_inx on test(id);

索引已建立。

SQL> create index name_inx on test(name);

到此該表已經可以正常使用了，但同時也丢失了一些資料，是以在使用dbms_repair進行恢複的時候要充分考慮到資料的重要性和恢複的後果。同時也應該考慮是否有其它别的恢複方法，不然貿貿然的行事最後可能得不償失。