oracle block corrupt 坏块

整体上来讲，oracle的坏块能够分为两种情景：物理损坏和逻辑损坏。物理损坏是因为存储等原因造成的，致使oracle在处理数据块时发现块的checksum不一致。逻辑损坏多是因为oracle的bug或者内存错误引起，通过检測数据块的checksum并不会发现什么问题，可是在逻辑上这些块已经发生了损坏。

oracle通过两个參数来控制对物理损坏和逻辑损坏的检測：

SQL> show parameter db_block_check

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
db_block_checking		     string	 FALSE
db_block_checksum		     string	 TRUE

db_block_checking 是当block发生不论什么变化的时候进行逻辑上的完整性和正确性检查。

该參数可以避免内存中数据块的损坏。

块的检查将对系统会有1%到10%的性能影响。取决于对db_block_checking參数的设置。频繁的DML将使得块检查带来很多其它的开销。

在系统负荷同意的情形下建议设置为full。

该參数对SYSTEM表空间始终是处于“打开”状态。而无论该參数是否设置为OFF。以下是该參数的设置參考。

FALSE和TRUE是为了老版本号的兼容。

Property             Description

---------------     ------------

Parameter type         String

Syntax                         DB_BLOCK_CHECKING = { FALSE| OFF| LOW | MEDIUM | TRUE| FULL}  -->OFF(=FALSE),FULL(=TRUE)

Defaultvalue              FALSE

Modifiable                  ALTER SYSTEM

Basic                          No

这里有一点须要注意，即仅仅有在对数据块发生改动时。db_block_checking才会发生作用。如

SQL> show parameter db_block_check

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
db_block_checking		     string	 FALSE
db_block_checksum		     string	 TRUE
SQL> alter system flush buffer_cache;

System altered.

SQL> select * from scott.s2;//查询时没有问题

T1	   T2
---------- --------------------
51809	   lllll
51888	   SC
51574	   PK_DEPT
51573	   DEPT
1575EMP,  5
51576	   PK_EMP
51578	   SALGRADE

7 rows selected.

SQL> update scott.s2 set t2=‘aaaa‘ where t1=‘51809‘;//改动也没有问题

1 row updated.

SQL> commit;

Commit complete.

SQL> alter system flush buffer_cache;

System altered.

SQL> alter system set db_block_checking=true;

System altered.

SQL> select * from scott.s2;//查询是没有问题的

T1	   T2
---------- --------------------
51809	   aaaa
51888	   SC
51574	   PK_DEPT
51573	   DEPT
1575EMP,  5
51576	   PK_EMP
51578	   SALGRADE

7 rows selected.

SQL> update scott.s2 set t2=‘bbbb‘ where t1 = ‘51809‘;//改动时触发了逻辑检測
update scott.s2 set t2=‘bbbb‘ where t1 = ‘51809‘
             *
ERROR at line 1:
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [kddummy_blkchk], [5], [20], [6113],
[], [], [], []

SQL> select * from scott.s2;//发现逻辑错误后，oracle将块标记为坏块。此时数据块无法訪问了
select * from scott.s2
*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 5, block # 20)
ORA-01110: data file 5: ‘/home/app/oraten/oradata/oraten/tbs201.dbf‘

db_block_checksum 用于DBWn和direct loader数据块写入到磁盘时。基于块内的全部字节计算得出一个校验值并将其写入块头。在该參数设置为typical和full时，当读入时候又一次计算校验和写出时候的校验对照。假设不同则觉得是块损坏。

假设设置为FULL模式，则基于update/delete应用程序语句级别的改变发生后，校验值会被又一次计算并写入。同一时候对于日志块。在写入之前。相同会生产校验值并写入到块头。

该參数主要是防止IO硬件和IO子系统的错误。假设设置为OFF则仅仅对系统表空间有效。

以下是该參数的设置參考。FALSE和TRUE是为了老版本号的兼容。

Property             Description

---------------     ------------

Parameter type         String

Syntax                         DB_BLOCK_CHECKSUM = { OFF| FALSE| TYPICAL | TRUE| FULL}  -->OFF(=FALSE),FULL(=TRUE)

Defaultvalue              TYPICAL

Modifiable                   ALTER SESSION,ALTER SYSTEM

Basic                          No

对于性能上的差异而言，当设置两个block參数设置为true时，将须要很多其它的CPU资源来生成校验值以及进行内存块的验证。

同一时候。该操作easy引起redo copy latch的持有时间添加和引起这个latch的竞争。

无论db_block_checking和db_block_checksum这两个參数的值为何值，SYSTEM表空间都会进行做checking和checksum，能够通过隐含參数_db_always_check_system_ts设置为FALSE，但为了SYSTEM表空间数据安全。不建议将这个隐含參数值设置为FALSE。

我们已经知道。oracle 将坏块分为物理和逻辑损坏两种，那么当oracle发现物理或者逻辑损坏之后是怎样标记数据块从而使之后的操作知道该块是损坏块的那？

对于物理损坏。oracle不会进行不论什么的处理，在进行兴许处理时oracle会又一次计算checksum，仅仅要发现checksum不一致则觉得该块时物理损坏，并抛出01578错误。

对于逻辑损坏，当oracle第一次对数据块进行逻辑检測时，会抛出ora 600等错误。并改动数据块中的标记位，当下次訪问该数据块时，oracle检測标志位。假设发现标志位以置为逻辑损坏。则抛出ora 01578错误。当使用DBMS_REPAIR对坏块进行改动时，假设时物理损坏不作不论什么处理。假设时逻辑损坏，改动数据块的标志位。

在数据块中存在两个位置表示数据块为逻辑损坏（不标示物理损坏）,例如以下：

BBED> map /v
 File: /home/app/oraten/oradata/oraten/tbs201.dbf (5)
 Block: 20                                    Dba:0x01400014
------------------------------------------------------------
 KTB Data Block (Table/Cluster)

 struct kcbh, 20 bytes                      @0
    ub1 type_kcbh                           @0
    ub1 frmt_kcbh                           @1
    ub1 spare1_kcbh                         @2
    ub1 spare2_kcbh                         @3
    ub4 rdba_kcbh                           @4
    ub4 bas_kcbh                            @8
    ub2 wrp_kcbh                            @12
    <strong>ub1 seq_kcbh                            @14  </strong>
    ub1 flg_kcbh                            @15
    ub2 chkval_kcbh                         @16
    ub2 spare3_kcbh                         @18      

 struct ktbbh, 96 bytes                     @20
    ub1 ktbbhtyp                            @20
    union ktbbhsid, 4 bytes                 @24
    struct ktbbhcsc, 8 bytes                @28
    b2 ktbbhict                             @36
    ub1 ktbbhflg                            @38
    ub1 ktbbhfsl                            @39
    ub4 ktbbhfnx                            @40
    struct ktbbhitl[3], 72 bytes            @44      

 struct kdbh, 14 bytes                      @124
    ub1 kdbhflag                            @124
    b1 kdbhntab                             @125
    b2 kdbhnrow                             @126
    sb2 kdbhfrre                            @128
    sb2 kdbhfsbo                            @130
    sb2 kdbhfseo                            @132
    b2 kdbhavsp                             @134
    b2 kdbhtosp                             @136     

 struct kdbt[1], 4 bytes                    @138
    b2 kdbtoffs                             @138
    b2 kdbtnrow                             @140     

 sb2 kdbr[7]                                @142     

 ub1 freespace[7905]                        @156     

 ub1 rowdata[127]                           @8061    

<strong> ub4 tailchk                                @8188</strong>
BBED> set offset 14
	OFFSET         	14

BBED> dump /v count 12
 File: /home/app/oraten/oradata/oraten/tbs201.dbf (5)
 Block: 20      Offsets:   14 to   25  Dba:0x01400014
-------------------------------------------------------
 <strong>ff</strong>0425fe 00000100 0000fcca          l ..%.........

 <16 bytes per line>

BBED> set offset 8188
	OFFSET         	8188

BBED> dump /v count 12
 File: /home/app/oraten/oradata/oraten/tbs201.dbf (5)
 Block: 20      Offsets: 8188 to 8191  Dba:0x01400014
-------------------------------------------------------
 <strong>ff</strong>060000                            l ....

这里的ff即标示数据块位逻辑损坏块，我们能够将其手工改动位01 或者 02 从而取消逻辑损坏标示。

对于已经标示为逻辑损坏的数据块，dbv等工具的检測结果例如以下：

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 1
Total Blocks Failing   (Data) : 0
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0

而对于没有标示的逻辑损坏，dbv等工具检測结果例如以下：

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 1
Total Blocks Failing   (Data) : 1
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0

对于物理损坏。dbv检測结果例如以下

DBVERIFY - Verification complete

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 0
Total Blocks Failing   (Data) : 0
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 1
Total Blocks Influx           : 0

对于dbms_repair包，假设是物理损坏，则REPAIR_TABLE的marked_corrupt列始终为true。fix方法并不会发生作用。对于逻辑损坏，首先repair_table 的marked_corrupt列为false，fix方法修正后。marked_corrupt改动为true，此时数据块的标志位已发生改动。

时间： 2024-11-10 00:14:38

oracle block corrupt 坏块的相关文章

Oracle corrupt block（坏块） 详解

转自:http://blog.csdn.net/tianlesoftware/article/details/5024966 一. 坏块说明 1.1 相关链接 在看坏块之前,先看几个相关的链接,在后面的说明中,会用到链接中的一些内容. ORA-600 各个参数含义说明 http://blog.csdn.net/tianlesoftware/article/details/6645809 Oracle 不同故障的恢复方案 http://blog.csdn.net/tianlesoftware/ar

Oracle 索引出现坏块处理

SQL> create table test as select * from dba_objects where rownum<1001; Table created. SQL> create index idx_test on test(object_id); Index created. SQL> select file_id, block_id, blocks from dba_extents where owner = 'LILC' and segment_name =

学习笔记:Oracle dul数据挖掘 导出Oracle11G数据文件坏块中表中

试验模拟导出Oracle 11G数据库中数据文件坏块中表中的数据 以前一直以为dul对应的版本只能恢复最高的数据库版本一致,今天测试发现dul 10可以恢复11g最新版的数据库.模拟环境 SQL> select * from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition

使用 DBMS_REPAIR 修复坏块

http://blog.csdn.net/leshami/article/details/10616687 Oracle corrupt block(坏块) 详解 http://blog.csdn.net/tianlesoftware/article/details/5024966

如何处理Oracle数据库中的坏块问题

本文主要介绍如何去处理在Oracle数据库中出现坏块的问题,对于坏块产生在不同的对象上,处理的方法会有所不同,本文将大致对这些方法做一些介绍.因为数据库运行时间长了,由于硬件设备的老化,出现坏块的几率会越来越大,因此,做为一个DBA,怎么去解决数据库出现的坏块问题就成了一个重要的议题了. 一:什么是数据库的坏块   首先我们来大概看一下数据库块的格式和结构 数据库的数据块有固定的格式和结构,分三层:cache layer,transaction layer,data layer.在我们对数据块进

Oracle数据库坏块的恢复

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

使用BBED模拟Oracle数据库坏块

BBED(OracleBlockBrowerandEDitor Tool),用来直接查看和修改数据文件数据的一个工具,是Oracle一款内部工具,可以直接修改Oracle数据文件块的内容,在一些极端恢复场景下比较有用.该工具不受Oracle支持,所以默认是没有生成可执行文件的,在使用前需要重新连接. 1.安装BBED [[email protected] lib]$ pwd /u02/app/product/10.2.0/db_1/rdbms/lib [[email protected] lib

使用BBED修复Oracle坏块恢复方法

BBED是Block Browser/Editor的缩写,是Oracle的一个内部工具,不对外发布文档及支持. BBED随软件发布,但是我们需要进行简单的relink才能使用. 虽然BBED工具的使用存在很多风险,但是如果利用得当,可以以之解决很多棘手的问题,并且可以练习坏块修复等技术. 例如在Oracle10g中的bbed工具,同样需要我们手工relink才能使用,这个版本的工具同样可以在其他版本的数据库中使用: [[email protected] lib]$ make -f ins_rdb

Oracle Rman修复逻辑坏块

RMAN 实现数据块恢复试用Rman可以实现数据块级的数据恢复,在传统恢复手段中即某个数据文件的一个数据块被损坏,就造成整个数据文件无法试用,此时必须通过备份恢复整个数据文件.显然这样的方法会会时间较长,而RMAN实现块级恢复,如果某个数据文件的数据损坏,通过数据文件的完整备份就可以恢复数据块. 案例:数据库是一个单实例ORACLE数据库,该库的总大小有700G.存储设备使用华为存储,备份设备使用希捷3T的移动硬盘.该数据库无DG无OGG.备份策略为每周六0点全库备份,周三0点1级差异备份其余时