mysql修复坏块_无备份时用dbms_repair恢复坏块的方法

份的情况下可以直接使用备份来恢复。

对于通过备份恢复，Oracel为我们提供了很多种方式，冷备，基于用户管理方式，RMAN方式等等。

对于这几种方式我们需要实现基于数据库以及文件级别的恢复。RMAN同时也提供了基于块介质方式的恢复。

也就是说我们根本不需要还原数据文件，而是直接从备份文件基于块来提取以实现联机恢复。

可参考基于RMAN实现坏块介质恢复(blockrecover) 。这是比较理想的情形。如果没有任何备份怎么办？

我们可以使用Oracle自带的DBMS_REPAIR包来实现修复。注意，不要被文章题目有所误导。

这里的修复是有损修复也就是说将受损的数据块标记为坏块，不对其进行访问而已。

就好比我们磁盘有坏道，找个磁盘修复工具将坏道标出来不使用，同理。

那受损的数据岂不是无力回天啦，呜呜......要记得随时备份阿。。1、DBMS_REPAIR包所含的过程

Procedure_Name       Description-----------------    ------------------------------------

ADMIN_TABLES         Provides administrative functions (create, drop, purge) for repair or orphan keytables.

Note: These tables are always createdin the SYS schema.

CHECK_OBJECT         Detectsand reports corruptions in a table or indexDUMP_ORPHAN_KEYS     Reportson index entries that point to rows incorrupt data blocks

FIX_CORRUPT_BLOCKS   Marks blocksas software corrupt that have been previously identified as corrupt by the CHECK_OBJECT procedureREBUILD_FREELISTS    Rebuilds the free listsofthe object

SEGMENT_FIX_STATUS   Provides the capabilityto fix the corrupted state of a bitmap entry when segment space management isAUTO

SKIP_CORRUPT_BLOCKSWhen used, ignores blocks marked corrupt during table and indexscans.If not used, you get error ORA-01578 whenencountering blocks marked corrupt.2、DBMS_REPAIR的一些局限性

Tableswith LOB data types, nested tables, and varrays are supported, but the out-of-line columns are ignored.

Clusters are supportedin the SKIP_CORRUPT_BLOCKS and REBUILD_FREELISTS procedures, but not in the CHECK_OBJECT procedure.Index-organized tables and LOB indexes are notsupported.

The DUMP_ORPHAN_KEYSprocedure does not operate on bitmap indexes or function-based indexes.

The DUMP_ORPHAN_KEYSprocedure processes keys that are no more than 3,950 bytes long.3、创建演示环境--当前环境

sys@USBO> select * from v$version where rownum<2;

BANNER--------------------------------------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 -Production--创建表空间

sys@USBO> create tablespace tbs_tmp datafile '/u02/database/usbo/oradata/tbs_tmp.dbf' size 10m autoextend on;--创建表对象tb_obj及其索引

sys@USBO> create table tb_obj tablespace tbs_tmp as select * fromdba_objects;

sys@USBO> create index i_tb_obj on tb_obj(object_id);--表段上的相关信息

sys@USBO> selectsegment_name , header_file , header_block,blocksfrom dba_segments where segment_name ='TB_OBJ';

SEGMENT_NAME HEADER_FILE HEADER_BLOCK BLOCKS------------------------------ ----------- ------------ ----------

TB_OBJ 6 130 1152

--使用linux自带的dd命令来损坏数据块

[oracle@linux1 ~]$ dd of=/u02/database/usbo/oradata/tbs_tmp.dbf bs=8192 conv=notrunc seek=131 <Corrupt me!>EOF0+1 records in

0+1records out12 bytes (12 B) copied, 0.000209854 seconds, 57.2 kB/s[oracle@linux1 ~]$ dd of=/u02/database/usbo/oradata/tbs_tmp.dbf bs=8192 conv=notrunc seek=141 <Corrupt me!>EOF0+1 records in

0+1records out12 bytes (12 B) copied, 0.00019939 seconds, 60.2 kB/s[oracle@linux1 ~]$ dd of=/u02/database/usbo/oradata/tbs_tmp.dbf bs=8192 conv=notrunc seek=151 <Corrupt me!>EOF0+1 records in

0+1records out12 bytes (12 B) copied, 2.1672e-05 seconds, 554 kB/s

sys@USBO> altersystem flush buffer_cache;--下面的查询收到了错误提示

sys@USBO> select count(*) fromtb_obj;select count(*) fromtb_obj*ERROR at line1:

ORA-01578: ORACLE data block corrupted (file # 6, block # 131)

ORA-01110: data file 6: '/u02/database/usbo/oradata/tbs_tmp.dbf'

4、使用DBMS_REPAIR修复坏块

Step a 创建相应的表对象--使用DBMS_REPAIR.ADMIN_TABLES过程创建一个表对象，用于记录需要被修复的表

sys@USBO> BEGINDBMS_REPAIR.ADMIN_TABLES (

TABLE_NAME=> 'REPAIR_TABLE',

TABLE_TYPE=>dbms_repair.repair_table,

ACTION=>dbms_repair.create_action,

TABLESPACE=> 'USERS');END;/PL/SQL proceduresuccessfully completed.--使用DBMS_REPAIR.ADMIN_TABLES过程创建一个表对象，用于记录在表块损坏后那些孤立索引，也就是指向坏块的那些索引

sys@USBO> BEGINDBMS_REPAIR.ADMIN_TABLES

(

TABLE_NAME=> 'ORPHAN_KEY_TABLE',

TABLE_TYPE=>DBMS_REPAIR.ORPHAN_TABLE,

ACTION=>DBMS_REPAIR.CREATE_ACTION,

TABLESPACE=> 'USERS');END;/PL/SQL proceduresuccessfully completed.

Step b 校验受损的对象--使用DBMS_REPAIR.CHECK_OBJECT来检测对象上受损的情形，并返回受损块数

sys@USBO> SET SERVEROUTPUT ONsys@USBO> DECLARE num_corrupt INT;BEGINnum_corrupt := 0;

DBMS_REPAIR.CHECK_OBJECT (

SCHEMA_NAME=> 'SYS',OBJECT_NAME => 'TB_OBJ',

REPAIR_TABLE_NAME=> 'REPAIR_TABLE',

CORRUPT_COUNT=>num_corrupt);

DBMS_OUTPUT.PUT_LINE('number corrupt:' ||TO_CHAR (num_corrupt));END;/

number corrupt: 3PL/SQL proceduresuccessfully completed.--下面我们可以从repair_table查询到受损的块--从下面的查询中可以看出列marked_corrupt全部为true，表明我们在CHECK_OBJECT已经标注了坏块--有一点不太清楚的是为什么块131在查询中被列出3次？

sys@USBO> COLUMN object_nameFORMAT a10

sys@USBO> COLUMNrepair_description FORMAT a28

sys@USBO> SET LINES 10000sys@USBO> SELECT object_name, block_id, corrupt_type,marked_corrupt,repair_description FROMrepair_table;

OBJECT_NAM BLOCK_ID CORRUPT_TYPE MARKED_COR REPAIR_DESCRIPTION---------- ---------- ------------ ---------- ----------------------------

TB_OBJ 131 6148TRUE mark block software corrupt

TB_OBJ131 6148TRUE mark block software corrupt

TB_OBJ131 6148TRUE mark block software corrupt

TB_OBJ141 6148TRUE mark block software corrupt

TB_OBJ151 6148TRUE mark block software corrupt

Step c 标记坏块--过程FIX_CORRUPT_BLOCKS用于标记坏块，在这个演示中，我们在CHECK_OBJECT已经被标注了，如没有执行下面的过程--由于上一步已经标注，所以下面的输出为0

sys@USBO> SET SERVEROUTPUT ONsys@USBO> DECLARE num_fix INT;BEGINnum_fix := 0;

DBMS_REPAIR.FIX_CORRUPT_BLOCKS (

SCHEMA_NAME=> 'SYS',OBJECT_NAME=> 'TB_OBJ',

OBJECT_TYPE=>dbms_repair.table_object,

REPAIR_TABLE_NAME=> 'REPAIR_TABLE',

FIX_COUNT=>num_fix);

DBMS_OUTPUT.PUT_LINE('num fix:' ||TO_CHAR(num_fix));END;/num fix:0

--Author : Robinson Cheng--Blog : http://blog.csdn.net/robinson_0612--DB forum : http://bbs.dbsupport.cn

PL/SQL proceduresuccessfully completed.

Step d DUMP孤立的索引键值--使用DUMP_ORPHAN_KEYS过程将那些指向坏块的索引键值填充到ORPHAN_KEY_TABLE

sys@USBO> SET SERVEROUTPUT ONsys@USBO> DECLARE num_orphans INT;BEGINnum_orphans := 0;

DBMS_REPAIR.DUMP_ORPHAN_KEYS (

SCHEMA_NAME=> 'SYS',OBJECT_NAME => 'I_TB_OBJ',

OBJECT_TYPE=>dbms_repair.index_object,

REPAIR_TABLE_NAME=> 'REPAIR_TABLE',

ORPHAN_TABLE_NAME=> 'ORPHAN_KEY_TABLE',

KEY_COUNT=>num_orphans);

DBMS_OUTPUT.PUT_LINE('orphan key count:' ||TO_CHAR(num_orphans));END;/orphankey count: 242PL/SQL proceduresuccessfully completed.--下面的查询可以看到正好等于上面返回的数量也就是242条记录

sys@USBO> select count(*) fromorphan_key_table;COUNT(*)----------

242

--验证对象是否可以查询，下面的结果显示依旧无法查询

sys@USBO> select count(*) fromtb_obj;select count(*) fromtb_obj*ERROR at line1:

ORA-01578: ORACLE data block corrupted (file # 6, block # 131)

ORA-01110: data file 6: '/u02/database/usbo/oradata/tbs_tmp.dbf'Step e 跳过坏块--使用SKIP_CORRUPT_BLOCKS来告知Oracle哪些坏块需要被跳过

sys@USBO> BEGINDBMS_REPAIR.SKIP_CORRUPT_BLOCKS (

SCHEMA_NAME=> 'SYS',OBJECT_NAME => 'TB_OBJ',

OBJECT_TYPE=>dbms_repair.table_object,

FLAGS=>dbms_repair.skip_flag);END;/PL/SQL proceduresuccessfully completed.--由于索引键上存在孤立索引，因此我们重建索引

sys@USBO> alter indexi_tb_obj rebuild;Indexaltered.--验证结果

sys@USBO> select count(*) fromtb_obj;COUNT(*)----------

72211

5、后记

a、再次提醒，备份重于一切，因此无论何时应保留可用的备份。

b、DBMS_REPAIR包并不是真正意思上的坏块修复，而是标记坏块，损坏的这部分数据被丢失。

c、DBMS_REPAIR包的几个步骤，先创建相应的表用于存储修复表及孤立索引，其次CHECK_OBJECT，FIX_CORRUPT_BLOCKS，DUMP_ORPHAN_KEYS，SKIP_CORRUPT_BLOCKS。

d、完整DBMS_REPAIR上面提到的几个步骤后，建议重建索引。

e、注，如果受损表对象被其他对象参照，建议先disable这些约束，那些在子表上孤立的记录可根据情形决定后再enable约束。---------------------

作者：Leshami

来源：CSDN

原文：https://blog.csdn.net/leshami/article/details/10616687版权声明：本文为博主原创文章，转载请附上博文链接！