Oracle Database物理坏块与逻辑坏块

一、数据库坏块介绍
数据库的数据块有固定的格式和结构，分三层：cache layer，transaction layer，data layer。在我们对数据块进行读取写入操作的时候，数据库会对要读写的数据块做一致性的检查，其中包括：数据块的类型、数据块的地址信息、数据块的SCN号以及数据块的头部和尾部。如果发现其中有不一致的信息，那数据库就会标记这个数据块为坏块了。

如果数据库出现坏块，数据库的告警日志文件里面会存在有如下的一些报错信息：Ora-1578、Ora-1110以及Ora-600 and trace file in bdump directory，其中Ora-600错误的第一个参数值的范围是[2000]-[8000]，不同的值代表着数据块的不同的层出现问题，具体的如下表所示：Range block layerCache layer 2000 – 4000Transaction layer 4000 – 6000Data layer 6000 - 8000

二、数据库坏块分类
数据库坏块(corruption)
1、按照坏块所属对象的不同，分为用户数据坏块，数据字典坏块，Undo坏块，控制文件坏块，Redo坏块，Lob坏块，index坏块等等。

2、按照坏块产生的原因，分为物理坏块(physical corruption)和逻辑坏块(logical corruption)。

三、物理坏块与逻辑坏块
物理坏块指的是块格式本身是坏的，块内的数据没有任何意义。
逻辑坏块指的是块内的数据在逻辑是存在问题。比如说索引块的索引值没有按从小到大排列。

常见的物理坏块（Physical Block Corruptions）有块头和块尾信息不一致(Fractured/Incomplete)，checksum值无效，数据块信息全部为0等情况，并且可能伴随错误ORA-1578和ORA-1110。

为了及时发现物理坏块和准确定位坏块产生的原因，oracle建议设置初始化参数DB_BLOCK_CHECKSUM=TYPICAL（默认值）。一般情况下，物理坏块是由于底层OS/disk系统错误/损坏，导致数据块被修改，数据块标志为坏块(corruption)。
数据块的Checksum值无效是一种常见的物理坏块，当数据库初始化参数DB_BLOCK_CHECKSUM=TYPICAL（默认值）时，DBWR进程将数据块写入disk时会计算数据块的Checksum，并且将Checksum值记录在数据块的位置offset 16和17；当从disk读取该数据块时，oracle重新计算数据块的Checksum，并且与记录在数据块中的Checksum做异或运算（Xor），如果异或结果为非0，说明数据块被修改过，数据块为坏块(corruption)。

四、数据库坏块产生的原因
1、硬件原因；
2、ORACLE与操作系统BUG；
3、操作系统的I/O错误或缓冲问题；
4、内存或paging问题；
5、非Oracle进程扰乱Oracle共享内存区域；
6、异常关机，掉电，终止服务；
7、硬盘修复工具；
8、一个数据文件的一部分正在被覆盖 ；
9、Oracle试图访问一个未被格式化的系统块失败；
10、数据文件部分溢出。

五、数据库坏块检查
1、SQL方式
在进行查询、更新等SQL发生报错数据库坏块；

2、日志报错记录
根据alert中的报错file_id和block_id查询对象。

3、RMAN方式（不产生备份）
RMAN备份时自动扫描数据库的物理错误和逻辑错误,检查数据文件是否有坏块，因为RMAN是ORACLE BLOCK级备份技术
RMAN 不需要执行备份操作也可以扫描数据库的物理错误和逻辑错误。 

RMAN> BACKUP CHECK LOGICAL VALIDATE DATAFILE n ; --检查某个数据文件逻辑坏块
RMAN> BACKUP CHECK LOGICAL VALIDATE DATABASE; --检查整个库逻辑坏块，结果放在v$database_block_corruption这个动态视图中。
RMAN> BACKUP VALIDATE DATABASE; --检查整个库物理坏块
RMAN> BACKUP VALIDATE DATAFILE n ; --检查某个数据文件物理坏块
注：另外还有VALIDATE…方式、RESTORE…VALIDATE方式检查。

4、ANALYSE方式
analyze table tablename validate structure cascade online(offline);
注：该命令同样会执行物理和逻辑一致性检查。除此之外，它还会检查表和索引条目的匹配性，检查分区表的记录是否在正确的分区中， 检查出的问题会放在USER_DUMP_DEST目录的trace文件中。

5、dbv工具检查
dbv file=+DATA/prod/datafile/apps_ts_tx_data.855.1047327187 blocksize=8192

6、利用expdp工具导出整个数据库可以检测坏块
对以下情况的坏块是检测不出来的：
HWM以上的坏块是不会发现的；
索引中存在的坏块是不会发现的；
数据字典中的坏块是不会发现的。
注：发现坏块就报错，不继续执行。另外无法检查逻辑坏块。

六、数据库坏块修复方法
前提：发现坏块后，首先要获得坏块的所属对象、文件号及块位置。
如果是索引、视图等坏块，可以删除重建。

1、首先确认坏块的对象（5文件号，9527为块号）
SELECT tablespace_name,segment_type, owner, segment_name FROM dba_extents WHERE file_id =5 AND 9527 between block_id AND block_id + blocks - 1;

2、查询所有坏块
select * from v$database_block_corruption;

修复方法：假设坏块为file # 5，block # 9527
3、通过RMAN备份恢复坏块（如果有备份）
RMAN> backup validate datafile 5; --检测数据文件物理坏块信息
RMAN> run {blockrecover datafile 5 block 9527;} --修复单个坏块
RMAN> run {blockrecover corruption list;} ----修复所有记录在V$DATABASE_BLOCK_CORRUPTION中的逻辑坏块。
RMAN> recover datafile ''; --修复数据文件
注：修复前建议备份原数据文件，表空间offline。

4、跳过坏块，导出数据并重建表后导入（如果没有备份）
数据导完后再根据业务将数据补齐。
SQL> alter session set db_file_multiblock_read_count=1;
SQL> execute DBMS_REPAIR.SKIP_CORRUPT_BLOCKS('schema_name','object_name');
SQL> create table dept_new as select * from table_name;