对Oracle数据库坏块的理解

1.物理坏块和逻辑坏块

      在数据库中有一个概念叫做数据块的一致性，Oracle的数据块的一致性包括了两个层次：物理一致性和逻辑一致性，如果一个数据块在这两个层次上存在不一致性，那就对应到了我们今天要要说的物理坏块和逻辑坏块。

      在每一个数据块的头部有一个校验和字段，每当数据块要被写回磁盘前，Oracle都会重新计算 这个数据块的校验和，并记录到这个字段最终写会磁盘。下次数据块被读入内存，Oracle会重新 计算数据块的校验和，并和块头的字段相比较，如果有差异，Oracle就知道这个数据块有错误， 会报出ORA-1578错误。    通过校验和字段进行的检查就是物理一致性检查，这个功能可以让Oracle检查到所有底层的错误， 包括磁盘、存储、IO子系统，所以称做物理一致性检查。

     在Oracle中每当要修改一个数据块中，会先对数据块内容做一个一致性检查（如检查记录 是否被不存在的食物锁定、记录和索引是否对应等）。如果这种一致性检查失败，就会抛出 ORA-600的Internal错误。当Oracle检查到数据块的逻辑一致性时，会尝试对数据块做 Cache Recovery,如果不能把数据块恢复到一致状态，Oracle就会把这个数据块标志为 Software Corrupt,当有查询访问到这数据块时，也会抛出前面ORA-1578错误。

      物理一致性检查利用校验和字段工作，主要侧重于检查硬件故障，并不关心内容正确与否， 而逻辑一致性检查就是侧重于内容的检查，内容检查要比校验和检查复杂的多。 逻辑一致性检查内容要多于物理一致性检查。

 

2.发生坏块的原因

       造成数据块损坏的原因多种多样，可是因为物理原因导致，也可能人为原因或Oracle bug导致。比较常见的人为原因异常关机、掉电、终止服务使进程异常终止，从而破坏数据的完整性，导致坏块的产生。发生数据块损坏的原因时，最典型的表现是遇到ORA-01578错误（比如在全表扫描时），有时也可能是ORA-600内部错误。

 

3.检查数据块的一致性

    (1)使用初始化参数检查数据块的一致性

     通过设置初始化参数db_block_checksum=true/false来启用、关闭物理一致性检查，启用该参数这会 增加1%～2%的负载，Oracle推荐启用该参数。在Oracle9i、10g中,默认是启用的。

     通过设置参数db_block_checking=true可以启用数据块的逻辑一致性检查。启用该参数这会 增加1%～10%的负载，尤其DML操作越密集性能影响越大。在Oracle10g中这个参数 默认值是false,这将意味这数据库只对System表空间做逻辑一致性检查。

 

    (2)DBV工具对数据块物理/逻辑性检查

   详情：http://book.51cto.com/art/201108/287893.htm

 

    (3)analyze命令检查数据块一致性

     analyze命令有很多中用法，可以完成很多功能，具体可参考：http://blog.csdn.net/tianlesoftware/article/details/7055164

     analyze命令检查对象一致性：   analyze table tablename validate structure cascade online(offline);

     该命令同样会执行物理和逻辑一致性检查。除此之外，它还会检查表和索引条目的匹配性，检查分区表的记录是否在正确的分区中， 检查出的问题会放在USER_DUMP_DEST目录的trace文件中。

      使用该命令注意一下几个问题：

      *当检查分区表的记录是否在正确的分区时，可以把检查出来的记录的ROWID记录在一个特殊表中，这个表叫做invalid_rows,该表需要   使用utlvalid.sql脚本提前建立，检查语法：   analyze tablename validate structure into invalid_rows;  

      *如果检查索引，这个命令会检查数据块和索引的一致性，但是不会确认每条记录都有相应的索引项或这索引有对应的记录，  如果需要这种检查，需要使用cascade关键字。  

      *如果使用online子句，可以在DML操作时在线检查一致性，只是这时不会收集对象的统计信息；而如果使用offline表会被锁住。

 

    (4)使用rman工具检查

     *检查数据文件
      backup check logical validate [database];
 
     *检查单个数据文件
      backup check logical validate datafile 1,2;
 
     *检查整个库
      backup check logical validate database    检查的结果放在v$database_block_corruption这个动态视图中。

      *这个命令对系统性能有一定的影响。

 

     (5)使用dbms_repair.check_object方法执行检查
      详细可参考：http://blog.itpub.net/8494287/viewspace-1357457/

 

  (6)利用exp工具导出整个数据库可以检测坏块

    导出命令在执行中会报ORA-01578错误，在这错误提示中会提示那个文件号的文件以及这个文件中的哪个块被损坏，如：ORA—01578：ORACLE 数据块损坏（文件号 4，块号 35）。利用exp工具进行检查坏块也局限性，对一些类型的坏块是检测不出来的如：HWM以上的坏块是不会发现的、索引中存在的坏块是不会发现的、数据字典中的坏块是不会发现的。

 

4.使用BBED模拟坏块

   http://www.cnblogs.com/myrunning/p/4433150.html

 

5.坏块的恢复理论

       对于发生数据块不一致的数据块，如果当前数据库有备份且处于归档模式，那么就可以利用rman工具数据块恢复功能对数据块进行恢复，这种方法最简单有效，而且可以在数据文件在线时进行，不会发生数据丢失。对于没有备份的数据库发生数据块损坏，可能会发生数据的丢失或数据不丢失，这要根据发生坏块的所在的对象决定的，如索引块发生损坏，数据就不会丢失，重建索引就可以了，发生数据丢失的多发生在表或分区表数据块上。

 

5.1.不丢数据的恢复方法

    利用rman工具：

        blockrecover datafile xx block yy;--修复单个坏块

        blockrecover corruption list;--修复全部坏块

如果坏块上的表最近都没有更新，还可以利用bbed的copy命令来从一个最近的备份中copy过来一个数据块恢复，具体不演示。

 

5.2.可能会丢数据的恢复方法

    5.2.1 确认坏块类型

        当一个坏块发生时，我们首先要确认这个块到底是什么样的块，是普通表的数据块（分区表的上数据块）、索引块等，针对不同的坏块类型我们来确认不同的恢复方法。

 

      <1>确定文件号

       Oracle有两种数据文件号来标识数据文件。绝对文件号(Absolute File#  AFN)和相对文件号(Relative File# RFN)。AFN是数据文件在整个系统范围内的编号，而RFN是数据文件在表空间范围内的编号。两个文件可能有相同的RFN,但是不会有相同的ASN。在ORA-01578中提示的文件号是RFN，在ORA-1110中提示的文件号是AFN，在ORA-600中提示的文件号为AFN,从视图中看到的文件号、数据块号属于哪个segment 使用的也是AFN 。

SQL> select tablespace_name,file_id "AFN",relative_fno "RFN"
  2  from dba_data_files;

TABLESPACE_NAME                       AFN        RFN
------------------------------ ---------- ----------
USERS                                   4          4
SYSAUX                                  3          3
UNDOTBS1                                2          2
SYSTEM                                  1          1
EXAMPLE                                 5          5
LIVAN_TBS                               6          6

6 rows selected.

 

SQL> select tablespace_name,file_id "AFN",relative_fno "RFN"
  2  from dba_temp_files;

TABLESPACE_NAME                       AFN        RFN
------------------------------ ---------- ----------
TEMP                                    1          1

 

        --利用AFN查询文件
        select name from v$datafile where file#=&AFN;

 

    <2>确认损坏数据块的类型

set lines 120
col segment_name for a20
col partition_name for a20
col owner for a10

select segment_name,partition_name,segment_type,owner,tablespace_name
from sys.dba_extents
where file_id=&AFN
and &bad_block_id between block_id and block_id + blocks-1;

 

   5.2.2按照不同的类型设置不同的恢复策略

 

     <1>用户表

        对于损害的数据块属于用户表的，数据丢失时不可避免的，这时需要做的就是把其他数据块中的数据抢救出来，而受损数据块的数据就永久丢失了。这时的恢复策略是尽可能的减少用户的损失。（如果这种数据损失不能接受，就必须考虑其他特殊手段来尝试恢复受损数据块中的数据）这种情况我们可以采用两种办法：
       *放弃坏块上的数据，抢救其他数据块上的数据，并重建对象;
       *把数据快标记为skiped,然后放任不管，也就是给这个数据块打上个标签，这样以后所有的操作都会跳过这个数据块。

 

       在处理数据表的坏块时，也要考虑关联对象的后续处理：

  --索引

select owner,index_name,index_type
from dba_indexes
where table_owner='&owner' and table_name='&semeng_name';

 

如果因为数据快损坏导致记录丢失，那么这些索引也就失效了，应该被删除，然后重建索引。

 

  --主键

     Oracle通过对主键字段创建唯一索引来实现主键约束，所以主键的处理方式和索引的处理方式一样，重建这个唯一索引。

select owner,constraint_name,constraint_type,table_name
from dba_constraints
where owner='&owner' and table_name='&segment_name'
and constraint_type='P';

 

--指向该主键的外键

查询出指向该主键的外键，主键外键处理方法相同，都需要重建索引。

select owner,constraint_name,constraint_type,table_name
from dba_constraints
where r_owner='&owner' and r_constraint_name='&constraint_name';

 

     <2>分区表

    分区表的处理和普通表类似，确认数据属于哪个分区，然后对受损的分区可以通过exchange操作，和一个相同表结构的空表进行交换，不影响程序的正常运行，然后与普通表相同的方法处理。

 

   
      <3>索引

      如果受损对象为索引，直接删除索引重建就可以了。

     对于普通表索引重建需要使用 alter index ... rebuild online语法，如果不带online关键字， 会依据旧的索引(包含坏块的)重建索引。 对于分区表索引，可以使用alter index xxx rebuild partition yyy的语句，因为分区索引的 重建不会使用旧索引，所以可以不加online关键字。

 

  索引坏块注意以下：

 ---确认索引所属的表

 select table_owner,table_name
from dba_indexes
where owner='&owner'  and index_name='&segment_name';

 

 

--如果是分区索引，查看属于分区

select partition_name
from dba_extents
where file_id=&AFN
and &bad_block_id between block_id and block_id + blocks-1;

 

--确认这个索引是否用于某个约束

select owner,constrint_name,constraint_type,table_name
from dba_constraints
where owner='&table_owner'
and constraint_name='&index_name';

 

--如果这个索引是主键索引，确认是否有外键指向这个索引

select owner,constraint_name,constraint_type,table_name
from dba_constraints
where r_owner='&owner' and r_constraint_name='&constraint_name';

 

 

   5.2.3恢复数据

       恢复数据就是把其他好的数据块中的数据全部抢救出来。简单地说就是把手损数据块标识成"software corrupt", 然后让Oracle做全表扫描时跳过这些块，而不是抛出异常，从而通过CTAS(create table xx as select ...)方法把数据抢救出来。

      要想让Oracle做全表扫描时跳过这些块（前提是先被打上"software corrupt"标记），可以使用两种方法： 使用dbms_repair包或使用10231事件。

     如果遇到ORA-1578错误，说明数据块已经被标识为"software corrupt"。如果是其他错误如ORA-600，就说明损坏的数据块还没有被标识为"software corrupt"。

      查看数据坏快是否被标记为"software corrupt"，可以通过DBMS_REPAIR.CHECK_OBJECT方法检查后查询REPAIR_TABLE表，如果数据块已经被标识成"software corrupt",那么 REPAIR_TABLE 表 marked_corrupt列为true,repair_description 列没内容。如果数据块没有被标识成"software corrupt",REPAIR_TABLE 表 marked_corrupt列为FALSE，repair_description列会提示"mark block software corrupt",也就是需要把数据块标识为"software corrupt"。

     当数据块被标识为"software corrupt"后，就可以利用 dbms_repair.skip_corrupt_blocks或者10231事件对segment做一个
标志，代表扫描该对象时如果遇到"software corrupt"的数据块可以直接跳过，而不是抛出ORA-01578错误终止，这样就可以完成对所有好的数据块的扫描，实现抢救数据。从视图dba_tables.skip_corrupt字段可以看出表是否设置了这个标志。

    ###dbms_repair方法

        设置标志：exec dbms_repair.skip_corrupt_block(,);
        设置完标识后再扫描到数据就不会提示错误，而是会在log日志中记录一条条目：
        table scan:segment file# 6 block# 4 skipping corrupt block file#6 block# 5
        清除标志：exec dbms_repair.skip_corrupt_block(,,flags=dbms_repair.noskip_flag);

      ###使用10231事件

      会话级别设置：alter session set events '10231 trace name context forever,level 10';

       通过初始化参数在实例级别设置：event="10231 trace name context forever,level 10";

 

 

5.坏块恢复实例

http://www.cnblogs.com/myrunning/p/4525917.html

 

 

 

 

参考： 张晓明<<大话Oracle RAC 集群 高可用 备份与恢复>>
http://blog.itpub.net/25472150/viewspace-688629/
http://blog.itpub.net/8494287/viewspace-1357457/
http://www.cnblogs.com/sumsen/archive/2013/01/20/2868740.html

 

 

 

 

     

 

转载于:https://www.cnblogs.com/myrunning/p/4430304.html