ITPub博客

首页 > Linux操作系统 > Linux操作系统 > db_block_checksum & db_block_checking

db_block_checksum & db_block_checking

原创 Linux操作系统 作者:hunterjoy 时间:2011-06-25 20:44:31 0 删除 编辑

摘自http://bitirainy.itpub.net/post/330/4216

这两个参数的含义经常让人混淆,虽然都是对block进行检查。

db_block_checksum 是在将数据块写到数据文件的时候对block内数据做一个校验写在块头,当读入时候重新计算校验和写出时候的校验对比,如果不同则认为是块损坏。这通常应该是由于脱离oracle以外在os或者硬件中出现了损坏,如果设置为false则只对系统表空间有效。从8i开始设置为true的时候也同时对log block进行校验。

db_block_checking 是当block发生任何变化的时候进行逻辑上的完整性和正确性检查,这在内存中进行,当发现错误就立即回退,设置为false则只对系统表空间有效。

这意味着,如果db_block_checking = false ,非系统表空间中数据在逻辑上可能已经损坏,但是 db_block_checksum 却是无法检查出来的,原样写到磁盘原样读到内存,因为它只校验块在写出后和读入之间是否发生变化而不检查写出前是否存在 逻辑上的正确。

比如有时索引块损坏,造成通过索引无法获得数据,但是读索引块的时候并没有出1578错误,可能就是这个原因

逻辑块修复办法:

错误提示:ORA-01578:ORACLE data block corrupted(file #20, block # 105407)   ORA-01110:data file 20:'/ud/oracle/oradata/users01.dbf',ORA-26040 ata block was loaded using the NOLOGGING option   于是我就按如下操作进行处理:
第一步:执行如下语句检查出坏块所在的段名等信息。
SELECT tablespace_name, segment_type, owner, segment_name  FROM dba_extents
WHERE file_id = 20  and 105407 between block_id AND block_id + blocks - 1;  查找出坏块所处的表空间名字,用户,段名等信息,执行结果如下:
TABLESPACE_NAME SEGMENT_TYPE
OWNER
SEGMENT_NAME

--------------- --------------- --------------- ---------------
TSP_INPBILL
TABLE
ERPP
INV_BILL_DETAIL


第二步:跳过坏块暂时让使用人员进行相关测试(注意:跳过这个坏块后,这个坏块上原来存放的数据将无法找回了)
执行如下语句:
execute DBMS_REPAIR.SKIP_CORRUPT_BLOCKS('ERPP','INV_BILL_DETAIL');

第三步:检查一下坏块是否已经跳过。执行如下语句:
SQL> execute DBMS_REPAIR.SKIP_CORRUPT_BLOCKS('ERPP','INV_BILL_DETAIL');
通过以上执行坏块已跳过了,可以执行查询了,如果执行更新,插入等操作不行的话,可以试着将原表数据备份,然后删除重新创建即可,这是我在工作上碰见到的一些心得跟大家分享一下。特别提醒大家,在数据库未能正常关闭,请不要通过杀进程这样的方法去处理该问题,否则,数据丢失无法挽回。切记!切记呀!

 

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/543979/viewspace-700728/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2007-12-31

  • 博文量
    158
  • 访问量
    357429