Oracle数据库应用程序中RAID的级别

        这篇论坛主要介绍了使用DBMS_REPAIR检测和修补数据坏块的具体方法，详细内容请参考下文。

提供了许多方法检测和修补数据库中的数据坏块，而DBMS_REPAIR package就是其中之一。

对任何可能导致数据丢失的损坏，我们都要仔细的分析，以求理解所要涉及的数据。就修补坏块本身来说, 它可能会丢失数据，也可能会导致数据在逻辑上不一致；因此在进行修补坏块之前，必须仔细权衡使用DBMS_REPAIR的得失。

DBMS_REPAIR package 仅仅对transaction层和data层的坏块(即通常所说的由软件引起的坏块)起作用，对物理上损坏的块，在它被读到缓冲区中时就已被标识出来了，而DBMS_REPAIR会忽略所有被标识为坏了的块。

在DBMS_REPAIR package 初始版本中，“修补坏块”的功能仅仅是“将块标识为由软件引起的坏块”

使用DBMS_REPAIR package的注意事项：

1、 DB_BLOCK_CHECKING和DB_BLOCK_CHECKSUM要设置为FALSE.

2、 在使用DBMS_REPAIR之前，有坏块的文件应做一个备份。

下面我们就通过一个例子来说明DBMS_REPAIR package是如何检测和修补坏块的。

例如，Table T1（结构如下）中存在一个坏块：

SQL> desc t1

Name Null? Type

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

COL1 NOT NULL NUMBER(38)

COL2 CHAR(512)

用Analyze命令对Table t1进行分析后，会得到如下错误提示：

SQL> analyze table t1 validate structure;

analyze table t1 validate structure

*

ERROR at line 1:

ORA-01498: block check failure

在Analyze产生的trace文件中，可以知道坏块中包含3条记录的数据(nrows = 3)，

Trace文件中主要的内容如下：

Dump file /export/home/oracle/product/8.1.5

/admin/V815/udump/v815_ora_2835.trc

8 Enterprise Edition Release 8.1.5.0.0

With the Partitioning option

*** 1998.12.16.15.53.02.000

*** SESSION ID:(7.6) 1998.12.16.15.53.02.000

kdbchk: row locked by non-existent transaction

table=0 slot=0

lockid=32 ktbbhitc=1

Block header dump: 0x01800003

Object id on Block? Y

seg/obj: 0xb6d csc: 0x00.1cf5f itc: 1 flg: - typ: 1 - DATA

fsl: 0 fnx: 0x0 ver: 0x01

Itl Xid Uba Flag Lck Scn/Fsc

0x01 xid: 0x0002.011.00000121 uba: 0x008018fb.0345.0d --U- 3 fsc

0x0000.0001cf60

data_block_dump

===============

tsiz: 0x7b8

hsiz: 0x18

pbl: 0x28088044

bdba: 0x01800003

flag=-----------

ntab=1

nrow=3

frre=-1

fsbo=0x18

fseo=0x19d

avsp=0x185

tosp=0x185

0xe:pti[0] nrow=3 offs=0

0x12:pri[0] offs=0x5ff

0x14:pri[1] offs=0x3a6

0x16:pri[2] offs=0x19d

block_row_dump:

(注：其余的省略)

end_of_block_dump

[1]     

【责编:Ken】

--------------------next---------------------