Oracle___诊断案例__解决佛山**支队数据坏块的问题(20061109)

1109上午，我和同事小汪一起到佛山，诊断解决数据坏块的问题，

问题：用户查询一个表时，报数据文件有坏块

目标：用户可以接受丢失这些坏块的数据，但该数据文件其它的好块应该可以查询数据。

下面是具体的步骤：

[@more@]

1.询问用户徐工出错的表名，收集出错信息
出错表名：
fsgazhjf.fsgazhjf_tac_20061018
trace文件中的出错信息：

***
Corrupt block relative dba: 0xb8428b33 (file 737, block 166707)
Fractured block found during user buffer read
Data in bad block -
type: 6 format: 2 rdba: 0xb8428b33
last change scn: 0x0000.0a66398d seq: 0x1 flg: 0x00
consistency value in tail: 0xbddc0601
check value in block header: 0x0, block checksum disabled
spare1: 0x0, spare2: 0x0, spare3: 0x0
***

2.根据出错块id，查询出该块对应的物理表，跟第一步收集的比对
select * from dba_extents
where file_id=737 and block_id <= 166707 and (block_id + blocks - 1) >= 166707;

FSGAZHJF FSGAZHJF_TAC_20061018 TABLE FSGAZHJF_GSM_10 1201 737 166665 1048576 128 737

结果：的确是该表:FSGAZHJF_TAC_20061018，用户FSGAZHJF，表空间FSGAZHJF_GSM_10

3.查询该表，看报错信息是否和第一步一致
select count(1) from fsgazhjf.fsgazhjf_tac_20061018;

结果：果然报错

4.收集该表的所有索引
select * from dba_indexes where owner='FSGAZHJF' and lower(table_name)='fsgazhjf_tac_20061018';
no rows
结果：无索引

5.用dbv工具来check bad block
SQL> select file_id||' '||file_name from dba_data_files where file_id=737;

FILE_ID||''||FILE_NAME
------------------------------------------------------------------------------
--------------------
737 K:ORADATAORA8FSGAZHJF_GSM_10_50.DBF

C:>dbv file='K:ORADATAORA8FSGAZHJF_GSM_10_50.DBF' blocksize=8192 logfile='h:dbv.log'

DBVERIFY: Release 8.1.7.4.1 - Production on 星期四 11月 9 10:57:13 2006

(c) Copyright 2000 Oracle Corporation. All rights reserved.

DBVERIFY: Release 8.1.7.4.1 - Production on 星期四 11月 9 10:57:13 2006

(c) Copyright 2000 Oracle Corporation. All rights reserved.

DBVERIFY - 检验开始：FILE = K:ORADATAORA8FSGAZHJF_GSM_10_50.DBF
标记为损坏的页面166708
***
Corrupt block relative dba: 0xb8428b34 (file 0, block 166708)
Bad header found during dbv:
Data in bad block -
type: 6 format: 2 rdba: 0xcf012b08
last change scn: 0x0000.0a91bf69 seq: 0x1 flg: 0x00
consistency value in tail: 0x0ccc0601
check value in block header: 0x0, block checksum disabled
spare1: 0x0, spare2: 0x0, spare3: 0x0
***

标记为损坏的页面166709
***
Corrupt block relative dba: 0xb8428b35 (file 0, block 166709)
Bad header found during dbv:
Data in bad block -
type: 6 format: 2 rdba: 0xce00e7e9
last change scn: 0x0000.0a910ce8 seq: 0x1 flg: 0x00
consistency value in tail: 0x0ce80601
check value in block header: 0x0, block checksum disabled
spare1: 0x0, spare2: 0x0, spare3: 0x0
***

标记为损坏的页面166710
***
Corrupt block relative dba: 0xb8428b36 (file 0, block 166710)
Bad header found during dbv:
Data in bad block -
type: 6 format: 2 rdba: 0xce00e7ea
last change scn: 0x0000.0a910ce8 seq: 0x1 flg: 0x00
consistency value in tail: 0x0ce80601
check value in block header: 0x0, block checksum disabled
spare1: 0x0, spare2: 0x0, spare3: 0x0
***

标记为损坏的页面166711
***
Corrupt block relative dba: 0xb8428b37 (file 0, block 166711)
Bad header found during dbv:
Data in bad block -
type: 6 format: 2 rdba: 0xce00e7eb
last change scn: 0x0000.0a910ce8 seq: 0x1 flg: 0x00
consistency value in tail: 0x39910601
check value in block header: 0x0, block checksum disabled
spare1: 0x0, spare2: 0x0, spare3: 0x0
***

DBVERIFY - 完成检验

检查的页面总数 ：262144
处理的页面总数（数据）：262010
失败的页面总数（数据）：0
处理的页面总数（索引）：0
失败的页面总数（索引）：0
处理的页面总数（其它）：9
空的页面总数 ：120
标记损坏的页面总数：4
汇集的页面总数 ：0

检查结果：4个坏块，块号是166708 ~ 166711 ，经查询，发现都在一个extent里，属于同一张表

6.开始打标记
具体过程：
C:>sqlplus sys/change_on_install

SQL*Plus: Release 8.1.7.0.0 - Production on 星期四 11月 9 12:18:08 2006

(c) Copyright 2000 Oracle Corporation. All rights reserved.

连接到:
Oracle8i Enterprise Edition Release 8.1.7.4.1 - Production
With the Partitioning option
JServer Release 8.1.7.4.1 - Production

SQL>exec dbms_repair.admin_tables('REPAIR_TABLE',1,1,'USERS');

PL/SQL 过程已成功完成。

SQL>exec dbms_repair.admin_tables('ORPHAN_TABLE',2,1,'USERS');

PL/SQL 过程已成功完成。

SQL> declare
2 cc number;
3 begin
4 dbms_repair.check_object(schema_name => 'FSGAZHJF',object_name => 'FSGAZHJF_TAC_20061018',corrupt_count => cc);
5 dbms_output.put_line(a => to_char(cc));
6 end;
7 /

PL/SQL 过程已成功完成。

SQL>
SQL> select count(1) from repair_table;

COUNT(1)
----------
5

***这里发现5个坏快，dbv发现的是4个
SQL>
***具体信息参考repair_table.xls

发现marked_corrupt列 已经为true,可能不需执行
exec dbms_repair.skip_corrupt_blocks(schema_name => 'FSGAZHJF',object_name => 'FSGAZHJF_TAC_20061018',flags => 1);
了，通过下面的查询，确认不需要执行了

SQL> select count(1) from FSGAZHJF.FSGAZHJF_TAC_20061018;

COUNT(1)
----------
18804767

7.为该表建立两个索引
建立成功

证明可以对该表进行全表扫描了，问题解决，但丢失5个块的数据

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

转载于:http://blog.itpub.net/8861952/viewspace-903697/