欢迎进入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]