[20140424]oracle的逻辑坏块.txt

[20140424]oracle的逻辑坏块.txt

今天上午本来想做一个11GR2的Automatic block media repair,链接如下:http://blog.itpub.net/267265/viewspace-1148315/

但是我遇到一个奇怪的问题,检查和的计算问题:

SYS@test> @ver
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

SCOTT@test> select rowid,a.* from dept1 a where deptno=60;
ROWID                  DEPTNO DNAME          LOC
------------------ ---------- -------------- -------------
AAAcC1AAIAAAACHAAA         60 MMMM           DDDDDz

SCOTT@test> @lookup_rowid AAAcC1AAIAAAACHAAA
    OBJECT       FILE      BLOCK        ROW DBA                  TEXT
---------- ---------- ---------- ---------- -------------------- ----------------------------------------
    114869          8        135          0 8,135                alter system dump datafile 8 block 135 ;

--关闭数据库.使用bbed看检查和.

BBED> set width 210
        WIDTH           210

BBED> set dba 8,135
        DBA             0x02000087 (33554567 8,135)

BBED> p *kdbr[0]
rowdata[0]
----------
ub1 rowdata[0]                              @8085     0x2c

BBED> x /rncc
rowdata[0]                                  @8085
----------
flag@8085: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8086: 0x00
cols@8087:    3

col    0[2] @8088: 60
col    1[4] @8091: MMMM
col    2[6] @8096: DDDDDz

BBED> sum
Check value for File 8, Block 135:
current = 0x8a26, required = 0x8a26

--使用bvi修改将'MMMM'替换成'AAAA'.
$ bvi -b 1105920 -s 8192 /u01/app/oracle11g/oradata/test/test01.dbf

BBED> sum
Check value for File 8, Block 135:
current = 0x8a26, required = 0x8a26
--可以发现与上面的一致,都是0x8a26.

--使用bvi修改成'BBBB'.
BBED> sum
Check value for File 8, Block 135:
current = 0x8a26, required = 0x8a26
--可以发现与上面的一致,都是0x8a26.

--使用bvi修改成'AAAM'.
BBED> sum
Check value for File 8, Block 135:
current = 0x8a26, required = 0x8626
--这个时候才出现不一致的情况.

--使用bvi修改成'1234'.
BBED> sum
Check value for File 8, Block 135:
current = 0x8a26, required = 0x8c24
--从这里看检查和的计算很容易出现重合的情况.

--继续测试
SYS@test> startup
ORACLE instance started.
Total System Global Area 1603411968 bytes
Fixed Size                  2228784 bytes
Variable Size            1006636496 bytes
Database Buffers          587202560 bytes
Redo Buffers                7344128 bytes
Database mounted.
Database opened.

SCOTT@test> show parameter db_block_
NAME               TYPE     VALUE
------------------ -------- --------
db_block_buffers   integer  0
db_block_checking  string   FULL
db_block_checksum  string   FULL
db_block_size      integer  8192

SCOTT@test> select rowid,a.* from dept1 a where deptno=60;

ROWID                  DEPTNO DNAME          LOC
------------------ ---------- -------------- -------------
AAAcC1AAIAAAACHAAA         60 MMMM           DDDDDz
--结果一致.

--查看alert*.log
Hex dump of (file 8, block 135) in trace file /u01/app/oracle11g/diag/rdbms/test/test/trace/test_ora_11802_127_0_0_1.trc
Corrupt block relative dba: 0x02000087 (file 8, block 135)
Bad check value found during multiblock buffer read
Data in bad block:
type: 6 format: 2 rdba: 0x02000087
last change scn: 0x0000.c2e5d41e seq: 0x1 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0xd41e0601
check value in block header: 0x8a26
computed block checksum: 0x602
Reading datafile '/u01/app/oracle11g/oradata/test/test01.dbf' for corruption at rdba: 0x02000087 (file 8, block 135)
Reread (file 8, block 135) found same corrupt data (no logical check)
Starting background process ABMR
Thu Apr 24 10:59:45 2014
ABMR started with pid=39, OS id=11804
Automatic block media recovery service is active.
Automatic block media recovery requested for (file# 8, block# 135)
Thu Apr 24 10:59:46 2014
Automatic block media recovery successful for (file# 8, block# 135)
Automatic block media recovery successful for (file# 8, block# 135)

--看来如果检查和出现重合的情况,oracle无法知道该块是否修改过,或者是逻辑损坏的.

时间: 2024-09-18 01:34:30

[20140424]oracle的逻辑坏块.txt的相关文章

oracle中RMAN备份和检查逻辑坏块

1. RMAN备份时是默认检查物理坏块. 2. 如果要检查逻辑坏块,可以用如下语句: $ rman target / RMAN> backup check logical validate database; 注上述语句,只是检查,不会备份的. 3. 如果要在备份的同时,进行逻辑坏块检查,可以用: $ rman target / RMAN> backup check logical database; 4.如果发现坏逻辑如何处理,下面补充一篇教程. 利用RMAN检测数据库坏块的脚本 虽然我们也

[20160722]对象C_OBJ#_INTCOL#有坏块.txt

[20160722]对象C_OBJ#_INTCOL#有坏块.txt --前几天看到的帖子,一直没时间测试,链接如下: http://www.itpub.net/thread-2063836-1-1.html --我以前按照eygle的链接http://www.eygle.com/archives/2012/05/event_38003_c_obj_intcol.html做过测试,测试在11.2.0.2下做的. --通过设置alter system set event='38003 trace n

[20150601]rman备份出现坏块.txt

[20150601]rman备份出现坏块.txt --昨天看链接: http://www.jydba.net/磁盘损坏造成RMAN备份文件有坏块的恢复案例/ --提到如果备份片存在坏块的恢复案例,他使用的参数,我自己从来没见过. alter system set event='19548 trace name context forever', '19549 trace name context forever' scope=spfile; -- oerr ora 19548,oerr ora

Oracle 9i数据坏块的处理实例

笔者在一台生产用测试库上SELECT一个表时出现ORA-01578,一个块损坏,以前学习过块损坏怎么处理,到还真没遇到过,今天总算让我遇到了,还是一台生产用测试库,就不用很紧张了. 数据库版本是9.2.0.4,Oracle9i的RMAN有一个blockrecover命令,可以在线修复坏块,以下就是使用RMAN修复坏块的过程. SQL> conn owi/owi Connected. SQL> select * from dpa_history; select * from dpa_histor

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

oracle|数据|数据库|问题 Oracle的数据块有固定的格式和结构,分三层: Cache layer.Transaction layer和Data layer.对数据块进行读写操作时,做一致性检查:–Block type–DBA–Scn –Header and tail 发现不一致,标记为坏块. 坏块有两种: 物理坏块和逻辑坏块. 坏块产生的影响:数据字典表.回滚段表.临时段和用户数据表和索引.应用报错:–Ora-1578 –Ora-600 and trace file in bdump

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

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

处理Oracle数据库中的坏块

一 什么是数据库的坏块 首先我们来大概看一下数据库块的格式和结构--数据库的数据块有固定的格式和结构,分三层 cache layer,transaction layer,data layer.在我们对数据块进行读取写入操作的时候,数据库会对要读写的数据块做一致性的检查,其中包括 数据块的类型.数据块的地址信息.数据块的SCN号以及数据块的头部和尾部.如果发现其中有不一致的信息,那数据库就会标记这个数据块为坏块了.数据库的坏块分为两种,逻辑坏块和物理坏块. 二 坏块对数据库产生的影响 如果数据库出

Oracle坏块问题处理 Oracle坏块修复 Oracle坏块怎么办

Oracle数据库出现坏块现象是指:在Oracle数据库的一个或多个数据块(一个数据块的容量在创建数据库时由db_block_size参数指定,缺省为8K)内出现内容混乱的现象.由于正常的数据块都有固定的合法内容格式,坏块的出现,导致数据库进程无法正常解析数据块的内容,进而使数据库进程报错乃至挂起,并级联导致整个数据库实例出现异常. 一.坏块分类 物理坏块:也可以称为介质坏块,指的是块格式本身是坏的,块内的数据没有任何意义. 逻辑坏块:指的是块内的数据在逻辑是存在问题.比如说索引块的索引值没有按

oracle中一次dataguard坏块的修复

客户有个11g的active dataguard库,mrp进程停了,看alertlog,可以看到有关ora-7445[kdxlin]的报错: cat alert*.log .... Exception [type:SIGSEOV,Address not mapped to object] [ADDR:0xC] |PC:0x96504C7,kdxlin()+4153][flags: 0x0,count:1] Errors in le /aabb/app/oracle/rdbms/diag/rdbm