数据库修复【block corruption recovery】

测试环境：

操作系统：windows7(32bit)

oracle数据库：11.2g

       数据块损坏分为两种，一种是物理损坏（physical corruption，也叫media corruption），一种是逻辑损坏（logical corruption）.每个数据块的块头都有一个校检和（checksum）。在一个数据块被写回磁盘之前，oracle会重新计算校验和，并且把该校验和记录到该字段中。在一个数据块被读入内存的时候，oracle会重新计算校验和并和该字段进行比较。若有差异，就会抛出ORA-1578异常，此时可以判断该数据块是损坏的。数据块的损坏会直接报错为数据文件的损坏。简而言之，“写回时，计算并保存；读入时，计算并比较，判一致性”。

      物理损坏的时候，校检和是无效的。数据块的内容已经被损坏。db_block_checksum参数被设为true时，oracle会对所有表空间的数据块以及redo log数据块进行校验和核对；若为false，则只会对system表空间的数据块进行校验和核对。oracle 建议开启该参数。

      逻辑损坏的时候，校检和是有效的，但是内容在逻辑上是不一致的。其的出现通常是oracle bug导致，可以通过重建等方式解决。通过RMAN的validate语法加上check logical语句才能检查。db_block_checking参数设为false,只会对system表空间进行逻辑一致性检查。对性能影响挺大的。

      v$database_block_corruption视图用来记录损坏的数据块，其corruption_type有6中类型的损坏数据块：

1、ALL ZERO:数据块头全部是零；     
2、FRACTURED:断裂块，在用户管理的备份模式中会出现这种数据块，数据块的内容可能是不同版本的，也就是header 和footer不一致。

3、CHECKSUM:数据块的内容不一致，可能是数据块中间数据来自不同版本；

4、CORRUPT:数据块被错误辨认或者那不是一个数据块（比如说数据块的地址丢失了）；

5、LOGICAL:逻辑损坏；

6、NOLOGGING:该数据块没有对应的日志记录，通常是由NOLOGGING操作造成。

   

一、模拟数据块损坏

       利用UltraEdit软件打开数据文件test01.dbf,然后随便修改里面的数据，这样就会给数据文件造成损坏了。

查询该数据文件中的一个表table1的时候，就会报错：