欢迎进入Oracle社区论坛，与200万技术人员互动交流 >>进入 6.3 BBED 工具 七。如何利用dbms_repair来标记和跳过坏块 但是当数据量很大，或7*24的系统时，我们使用dbms_repair来处理。dbms_repair是从oracle8i开始提供的。 准备工作： create tablespace bloc
欢迎进入Oracle社区论坛，与200万技术人员互动交流 >>进入
6.3 BBED 工具
七。如何利用dbms_repair来标记和跳过坏块
但是当数据量很大，或7*24的系统时，我们使用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;
COUNT（*）
12896
7.1.创建管理表：
SQL> conn sys/admin as sysdba;
已连接。
SQL> exec DBMS_REPAIR.ADMIN_TABLES（'REPAIR_TABLE',1,1,'USERS'）；
PL/SQL procedure successfully completed
SQL> exec DBMS_REPAIR.ADMIN_TABLES（'ORPHAN_TABLE',2,1,'USERS'）；
PL/SQL procedure successfully completed
7.2.检查坏块：dbms_repair.check_object
/* Formatted on 2009-12-16 23:41:32 （QP5 v5.115.810.9015） */
Set serveroutput on;
DECLARE
cc NUMBER;
BEGIN
DBMS_REPAIR.check_object （schema_name => 'SYS', -- 注意此处是用户名
object_name => 'DMM',
corrupt_count => cc）；
DBMS_OUTPUT.put_line （ TO_CHAR （cc））；
END;
正常情况下输入为0.
如果有坏块，可以在创建的REPAIR_TABLE中查看块损坏信息：
/* Formatted on 2009-12-17 13:18:19 （QP5 v5.115.810.9015） */
SELECT object_name,
relative_file_id,
block_id,
marked_corrupt,
corrupt_description,
repair_description,
CHECK_TIMESTAMP
FROM repair_table;
注意：在8i下，check_object只会检查坏块，MARKED_CORRUPT为false,故需要执行第三步：定位坏块，fix_corrupt_blocks定位，修改MARKED_CORRUPT为true,同时更新CHECK_TIMESTAMP.9i以后经过check_object,MARKED_CORRUPT的值已经标识为TRUE了。所以可以直接进行第四步了。
7.3.定位坏块：dbms_repair.fix_corrupt_blocks
只有将坏块信息写入定义的REPAIR_TABLE后，才能定位坏块。
/* Formatted on 2009-12-17 13:29:01 （QP5 v5.115.810.9015） */
DECLARE
cc NUMBER;
BEGIN
DBMS_REPAIR.fix_corrupt_blocks （schema_name => 'SYS',
object_name => 'DMM',
fix_count => cc）；
DBMS_OUTPUT.put_line （a => TO_CHAR （cc））；
END;
7.4.跳过坏块：
我们前面虽然定位了坏块，但是，如果我们访问table:
SQL> select count（*） from SYS.DMM;
ORA-01578: ORACLE 数据块损坏（文件号14,块号154）
ORA-01110: 数据文件 14: 'D: \BLOCK.DBF'
还是会得到错误信息。这里需要用skip_corrupt_blocks来跳过坏块：
/* Formatted on 2009-12-17 13:30:17 （QP5 v5.115.810.9015） */
exec dbms_repair.skip_corrupt_blocks（schema_name => 'SYS',object_name => 'DMM',flags => 1）；
SQL> select count（*） from SYS.DMM;
COUNT（*）
12850
丢失了12896-12850=46行数据。
7.5.处理index上的无效键值；dump_orphan_keys
/* Formatted on 2009-12-17 13:34:55 （QP5 v5.115.810.9015） */
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 => CC）；
END;
[1] [2] [3] [4]
