测试环境:
操作系统: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的时候,就会报错: