所以可以直接进行第四步了。

按照oracle文档上的说法，在8i下，check_object只会检查坏块，MARKED_CORRUPT为false

需要使用第3步，fix_corrupt_blocks定位 ，修改MARKED_CORRUPT为true，同时更新CHECK_TIMESTAMP。

这里我们经过实验，确认在9i下跳过第3步，是完全可行的。

那么8i是否需要执行第三步，我没有实验过，但推测应该是不可以跳过的。

3.定位坏块：dbms_repair.fix_corrupt_blocks

只有将坏块信息写入定义的REPAIR_TABLE后，才能定位坏块。

declare

cc number;

begin

dbms_repair.fix_corrupt_blocks(schema_name => DLINGER,object_name => TEST,fix_count => cc);

dbms_output.put_line(a => to_char(cc));

end;

4.跳过坏块：

我们前面虽然定位了坏块，但是，如果我们访问table：

SQL> select count(*) from dlinger.dbblock;

select count(*) from dlinger.dbblock

ORA-01578: ORACLE 数据块损坏（文件号14，块号154）

ORA-01110: 数据文件 14: D:ORACLEORADATAORACLE9IBLOCK.DBF

还是会得到错误信息。

这里需要用skip_corrupt_blocks来跳过坏块：

SQL> exec dbms_repair.skip_corrupt_blocks(schema_name => DLINGER,object_name => TEST,flags => 1);

PL/SQL procedure successfully completed

SQL> select count(*) from dlinger.test;

COUNT(*)

----------

12850

丢失了12896－12850＝46行数据。

5.处理index上的无效键值；dump_orphan_keys

declare

cc number;

begin

dbms_repair.dump_orphan_keys(schema_name => DLINGER,object_name => I_TEST,object_type => 2,

repair_table_name => REPAIR_TABLE,orphan_table_name => ORPHAN_TABLE,key_count => CC);

end;

/

SQL> SELECT * FROM ORPHAN_TABLE;

SCHEMA_NAME INDEX_NAME IPART_NAME INDEX_ID TABLE_NAME PART_NAME TABLE_ID KEYROWID KEY DUMP_TIMESTAMP

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

DLINGER I_TEST 30258 TEST 30257 AAAHYxAOwAAAIADA0A *BAAAAAAMTE9HTU5SQ19HU0lJ/g 2004-8-25 22:1

DLINGER I_TEST 30258 TEST 30257 AAAHYxAOwAAAIADAsA *BAAAAAAMTE9HTU5SQ19HVExP/g 2004-8-25 22:1

..............................................

DLINGER I_TEST 30258 TEST 30257 AAAHYxAOwAAAIADB0A *BAAAAAAPTE9HTU5SX0xPQkZSQUck/g 2004-8-25 22:1

DLINGER I_TEST 30258 TEST 30257 AAAHYxAOwAAAIADBYA *BAAAAAAMTE9HTU5SX1RZUEUk/g 2004-8-25 22:1

DLINGER I_TEST 30258 TEST 30257 AAAHYxAOwAAAIADAQA *BAAAAAALTE9HTU5SX1VJRCT+ 2004-8-25 22:1

DLINGER I_TEST 30258 TEST 30257 AAAHYxAOwAAAIADAoA *BAAAAAAMTE9HTU5SX1VTRVIk/g 2004-8-25 22:1