| 这篇论坛主要介绍了使用DBMS_REPAIR检测和修补数据坏块的具体方法，详细内容请参考下文。
oracle提供了许多方法检测和修补数据库中的数据坏块，而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
oracle8 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] [2] [3] [4] [5] 下一页 |
