坏块故障葵花宝典

1、Oracle坏块故障总结 最近处理了两次典型的ora-01578,ora-01115,ora-01110故障，一次是平湖索引块坏，一次是黄山数据文件坏、blob数据块坏。平湖的警告日志文件中有以下信息：ORA-12022: error on auto execute of job 21ORA-01578: ORACLE data block corrupted (file # 10, block # 2558610)ORA-01110: data file 10: 'D:ORACLEORADATABSUSERS04.DBF'ORA-12022: error on auto ex

2、ecute of job 1ORA-01578: ORACLE data block corrupted (file # 16, block # 2624066)ORA-01110: data file 16: 'D:ORACLEORADATABSUSERS10.DBF'应用软件可以正常使用，偶尔会报错ora-01578。排错过程登录数据库检查：select count(*) from ep_table t where ptime<trunc(sysdate)-30 and alarmtype=0784163select count(*) from ep_table t看

3、来全表扫描正常select from ep_table t where ptime<trunc(sysdate)-31 and ptime>trunc(sysdate)-33 and alarmtype=0 and rownum<10001索引扫描报错了，推断为索引上有坏块！继续查：select owner,file_id,segment_name, segment_type, block_id, blocksfrom dba_extentswhere file_id=16 and block_id<=2624066 and (block_id + blocks- 1)

4、 >= 2624066;OWNERFILE_IDSEGMENT_NAMESEGMENT_TYPEBLOCK_IDBLOCKSBS16VHINOINDEX16运气真好重建相关索引后数据库就恢复了。黄山坏块故障就比拟复杂了，硬盘坏导致多个数据文件的多个块故障，其中还有blob对象。Count(*)一张表报错：查询某张表系统事件中有报错：磁盘管理中报错：Dell的效劳器，2块72G硬盘，没有做raid,8i数据库没有备份。上图磁盘3为移动硬盘初步检查到这里我感觉这次坏的严重了，恢复可能比拟麻烦。整理一下思路：1、 不要随意重启2、 记录损坏的数据信息3、 导出可用数据4、 更换故障硬盘5、 重

5、做系统及数据库6、 恢复数据7、 重传丧失的数据我们的系统架构可以这样做排错过程select * from dba_extents where file_id=8 and 1461842 between block_id and block_id+blocks-11BSSYS_LOB0000003770C00017$LOBSEGMENTUSERS3457081461842131072168解释：block_id+blocks-1=+这个区有多少个block-1查到故障段为LOBSEGMENT类型，SYS_LOB0000003770C00017$。select dl.table_name,dl.

6、SEGMENT_NAME from dba_lobs dl where dl.owner=' BS' where dl.SEGMENT_NAME=' SYS_LOB0000003770C00017$'查到有坏块的表为EP_PECC。接着查出这张表的lob索引段Select A.TABLE_NAME,A.COLUMN_NAME,B.SEGMENT_NAME,B.SEGMENT_TYPE,B.HEADER_FILE,B.HEADER_BLOCK,B.BYTES from DBA_LOBS A,DBA_SEGMENTS B where A.INDEX_NAME=B.S

7、EGMENT_NAME AND A.TABLE_NAME='EP_PECC'当时因为没有记录，所以我随便举例：1EP_TABLETHIRDPICTSYS_IL0000052738C00018$LOBINDEX7155655362EP_TABLEPANORAMAPICTSYS_IL0000052738C00017$LOBINDEX7139655363EP_TABLEPLATEPICTSYS_IL0000052738C00016$LOBINDEX712365536select rowid from BS.EP_PECC where dbms_rowid.rowid_to_absol

8、ute_fno(rowid,'BS','EP_PECC')=8 and dbms_rowid.rowid_block_number(rowid)=1461842;这个块无法找出blob段的rowid。本想找后我可以按照rowid清空故障的blob数据。选择一个范围继续找：select rowid,T.PTIME,T.PLATEPICT,T.PANORAMAPICT from BS.EP_PECC T where dbms_rowid.rowid_to_absolute_fno(rowid,'BS','EP_PECC')=8 and

9、 dbms_rowid.rowid_block_number(rowid) BETWEEN 1461840 AND 1461842;还是没有找到select rowid, dbms_rowid.rowid_object(rowid) obj_id, dbms_rowid.rowid_relative_fno(rowid) df#, dbms_rowid.rowid_block_number(rowid) blknum, dbms_rowid.rowid_row_number(rowid) rowno ,T.PTIME,T.ALARMTYPE,T.PLATEPICT,T.PANORAMAPICT

10、from EP_PECC T where dbms_rowid.rowid_to_absolute_fno(rowid,'BS','EP_PECC')='8' AND dbms_rowid.rowid_block_number(rowid) BETWEEN 1461842 AND 1461842 +1024;还没找到select rowid, dbms_rowid.rowid_object(rowid) obj_id, dbms_rowid.rowid_relative_fno(rowid) df#, dbms_rowid.rowid_block

11、_number(rowid) blknum, dbms_rowid.rowid_row_number(rowid) rowno ,T.PTIME,T.ALARMTYPE,T.PLATEPICT,T.PANORAMAPICTfrom EP_PECC T where dbms_rowid.rowid_to_absolute_fno(rowid,'BS','EP_PECC')='8' AND dbms_rowid.rowid_block_number(rowid) BETWEEN 1461742 AND 1461842;终于找到了一些AAAA66AAI

12、AAFkrSAAJ37708146094692021-10-26 19:40:080<BLOB><BLOB>省略一些结果集AAAA66AAIAAFk5JAAG3770862021-10-26 19:47:080<BLOB><BLOB>查到以下记录时出错，看来按照rowid清空故障的blob数据不行AAAA66AAIAAFk5JAAGROWID_TYPE: 1OBJECT_NUMBER: 3770RELATIVE_FNO: 8BLOCK_NUMBER: ROW_NUMBER: 6可以从obj#,rfile#,block#,row#计算得到理论上的r

13、owid Obj# 3770Rfile# 8Block# 1461842Row# 0实际上就是将十进制数转化成64进制数，当然，从二进制转化的规那么比拟简单点。将二进制数从右到左，6个bit一组，然后将这6个bit组转成10进制数，就是AZ az 09 + /这64个字符的位置从0开始，替换成base64的字符即可。rowid是base64编码的，用AZ az 09 + /共64个字符表示。A表示0，B表示1，a表示26，0表示52，+表示62，/表示63可以将其看做一个64进制的数。obj#=3770转换成二进制，补足成6位base64编码，左边填0，结果为AAAA66rfile#=8=00

14、1000=I，补足成3位，得到AAIblock#=000101 100100 111001 010010=5 36 57 18，补足成6位，得到AAFk5Srow#=0，3位AAA合起来就是AAAA66AAIAAFk5SAAA但是不要忘了，这次坏的是blob它会跨多个块的。所以这条理论rowid没有找到！举例子补充说明：select * from dba_lobs dl where dl.owner='TEST'1TESTT_LOGRZSYS_LOB0000052726C00002$TESTSYS_IL0000052726C00002$8192900NOYESYESNOT AP

15、PLICABLE NO2TESTEP_TABLEPLATEPICTSYS_LOB0000052738C00016$TESTSYS_IL0000052738C00016$8192900NOYESYESNOT APPLICABLE NO3TESTEP_TABLEPANORAMAPICTSYS_LOB0000052738C00017$TESTSYS_IL0000052738C00017$8192900NOYESYESNOT APPLICABLE NO4TESTEP_TABLETHIRDPICTSYS_LOB738C00018$TESTSYS_IL0000052738C00018$8192900NOY

16、ESYESNOT APPLICABLE NO5TESTEP_PECCPLATEPICTSYS_LOB0000052746C00016$TESTSYS_IL0000052746C00016$8192900NOYESYESNOT APPLICABLE NO6TESTEP_PECCPANORAMAPICTSYS_LOB0000052746C00017$TESTSYS_IL0000052746C00017$8192900NOYESYESNOT APPLICABLE NO7TESTEP_PECCTHIRDPICTSYS_LOB0000052746C00018$TESTSYS_IL0000052746C0

17、0018$8192900NOYESYESNOT APPLICABLE NO没有任何数据时：select dl.TABLE_NAME,dl.COLUMN_NAME,de.segment_name,de.segment_type,de.FILE_ID,de.BLOCK_ID from dba_extents de,dba_lobs dl where de.owner='TEST' and dl.OWNER='TEST' and de.segment_name=dl.SEGMENT_NAME1T_LOGRZSYS_LOB0000052726C00002$LOBSEGM

18、ENT7172EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT71133EP_TABLEPANORAMAPICTSYS_LOB0000052738C00017$LOBSEGMENT71294EP_TABLETHIRDPICTSYS_LOB0000052738C00018$LOBSEGMENT71455EP_PECCPLATEPICTSYS_LOB0000052746C00016$LOBSEGMENT71776EP_PECCPANORAMAPICTSYS_LOB0000052746C00017$LOBSEGMENT71937EP_PECCTH

19、IRDPICTSYS_LOB0000052746C00018$LOBSEGMENT7209向EP_TABLE表的PLATEPICT字段，插入一张9MB大小的图片后结果：1T_LOGRZSYS_LOB0000052726C00002$LOBSEGMENT7172EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT71133EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT72734EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT72815EP

20、_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT72896EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT72977EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT73058EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT73139EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT732110EP_TABLEPLATEPICTSYS_

21、LOB0000052738C00016$LOBSEGMENT732911EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT733712EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT734513EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT735314EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT736115EP_TABLEPLATEPICTSYS_LOB0000052738C0

22、0016$LOBSEGMENT736916EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT737717EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT738518EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT6919EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT739320EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT61

23、3721EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT752122EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT626523EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT764924EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT639325EP_TABLEPLATEPICTSYS_LOB0000052738C00016$LOBSEGMENT777726EP_TABLEPLA

24、TEPICTSYS_LOB0000052738C00016$LOBSEGMENT652127EP_TABLEPANORAMAPICTSYS_LOB0000052738C00017$LOBSEGMENT712928EP_TABLETHIRDPICTSYS_LOB0000052738C00018$LOBSEGMENT714529EP_PECCPLATEPICTSYS_LOB0000052746C00016$LOBSEGMENT717730EP_PECCPANORAMAPICTSYS_LOB0000052746C00017$LOBSEGMENT719331EP_PECCTHIRDPICTSYS_LO

25、B0000052746C00018$LOBSEGMENT7209查test用户blob容量：select sum(de.BYTES/1024/1024) from dba_extents de,dba_lobs dl where de.owner='TEST' AND dl.OWNER='TEST' AND de.segment_name=dl.segment_name10.375显示10MB检查表建在那个数据文件那个块上SELECT DISTINCT dbms_rowid.rowid_relative_fno(rowid) AS "File"

26、;, dbms_rowid.rowid_block_number(rowid) AS "Block" FROM ep_table; FileBlock7110看起来这个表存放在文件号7，块号110的地方查找存放图片的blob段：select de.segment_name,de.EXTENT_ID,de.FILE_ID,de.BLOCK_ID,de.BYTES,de.BLOCKS,de.relative_fno from dba_extents de where de.owner='TEST' and de.segment_name='SYS_LOB

27、0000052738C00016$'我已经往这个段里存放了一张9MB的图片，占用了以下块。 SEGMENT_NAME EXTENT_IDFILE_IDBLOCK_IDBYTESBLOCKSRELATIVE_FNO1SYS_LOB0000052738C00016$0711365536872SYS_LOB0000052738C00016$1727365536873SYS_LOB0000052738C00016$2728165536874SYS_LOB0000052738C00016$3728965536875SYS_LOB0000052738C00016$4729765536876SYS_

28、LOB0000052738C00016$5730565536877SYS_LOB0000052738C00016$6731365536878SYS_LOB0000052738C00016$7732165536879SYS_LOB0000052738C00016$87329655368710SYS_LOB0000052738C00016$97337655368711SYS_LOB0000052738C00016$107345655368712SYS_LOB0000052738C00016$117353655368713SYS_LOB0000052738C00016$127361655368714

29、SYS_LOB0000052738C00016$137369655368715SYS_LOB0000052738C00016$147377655368716SYS_LOB0000052738C00016$157385655368717SYS_LOB0000052738C00016$16691048576128618SYS_LOB0000052738C00016$1773931048576128719SYS_LOB0000052738C00016$1861371048576128620SYS_LOB0000052738C00016$197521128721SYS_LOB0000052738C00

30、016$2062651048576128622SYS_LOB0000052738C00016$2176491048576128723SYS_LOB0000052738C00016$2263931048576128624SYS_LOB0000052738C00016$2377771048576128725SYS_LOB0000052738C00016$24652110485761286根据上一步查出来的BLOCK_ID一阵狂找，终于找到了select rowid, dbms_rowid.rowid_object(rowid) obj_id, dbms_rowid.rowid_relative_f

31、no(rowid) df#, dbms_rowid.rowid_block_number(rowid) blknum, dbms_rowid.rowid_row_number(rowid) rowno ,T.PTIME,T.ALARMTYPE,T.PLATEPICT,T.PANORAMAPICTfrom ep_table T where dbms_rowid.rowid_to_absolute_fno(rowid,'TEST','EP_TABLE')='7' AND dbms_rowid.rowid_block_number(rowid) BET

32、WEEN 1 AND 113; ROWIDOBJ_IDDF#BLKNUMROWNOPTIMEALARMTYPEPLATEPICTPANORAMAPICT1AAAM4CAAHAAAABuAAA52738711002021-11-29 22:51:580<BLOB><BLOB>看来它跨越了6号数据文件的9号块到7号数据文件的777号块根据rowid反过来验证一下块信息：declarev_rowid_type number;v_OBJECT_NUMBER number;v_RELATIVE_FNO number;v_BLOCK_NUMBERE_FNO number;v_ROW

33、_NUMBER number;begindbms_rowid.rowid_info(rowid_in => 'AAAM4CAAHAAAABuAAA',rowid_type => v_rowid_type,object_number => v_OBJECT_NUMBER,relative_fno => v_RELATIVE_FNO,block_number => v_BLOCK_NUMBERE_FNO,row_number => v_ROW_NUMBER);dbms_output.put_line('ROWID_TYPE: '|

34、to_char(v_rowid_type);dbms_output.put_line('OBJECT_NUMBER: '|to_char(v_OBJECT_NUMBER);dbms_output.put_line('RELATIVE_FNO: '|to_char(v_RELATIVE_FNO);dbms_output.put_line('BLOCK_NUMBER: '|to_char(v_BLOCK_NUMBERE_FNO);dbms_output.put_line('ROW_NUMBER: '|to_char(v_ROW_NUM

35、BER);end;/ROWID_TYPE: 1OBJECT_NUMBER: 52738RELATIVE_FNO: 7BLOCK_NUMBER: 110ROW_NUMBER: 0也就是说如果blob字段发生坏块，可能坏块的block_id为273，但是要查找记录的rowid的话需要前后跨越一段block_id才有可能找到，例如这里的110。而从obj#,rfile#,block#,row#计算得到理论上的rowid可能不存在。回到黄山坏块故障上：SELECT COUNT(*) FROM EP_PECC WHERE TO_CHAR(PTIME,'YYYYMMDD') >

36、9;20211125' AND TO_CHAR(PTIME,'YYYYMMDD') <'20211127'ERROR 位于第 1 行:ORA-01115: 从文件 8 读取块时出现 IO 错误 (块 # 1461842)ORA-01110: 数据文件 8: 'E:ORADATADZJCUSERS02.DBF'ORA-27091: skgfqio: 无法进行 I/O 操作OSD-04006: ReadFile() 失败,无法自文件读取O/S-Error: (OS 23) 数据错误 (循环冗余检查)。验证了这个时间段区间内的数据有坏块！

37、Select count(*) from EP_PECC t where PTIME< TO_DATE('20211027 20:47:57','yyyymmdd HH24:MI:SS') AND PTIME >TO_DATE('20211026 20:48:57','yyyymmdd HH24:MI:SS')没有报错结论：1461833块为 20211026 20:47:57到 20211026 20:48:57 之间。同时我也偷懒了没有继续查找因为连着坏了好多块。恢复完数据库后重传这段时间的记录就行了！备份时只需把

38、期间的数据备份出来就可以。DELETE from EP_PECC t where PTIME< TO_DATE('20211026 20:48:57','yyyymmdd HH24:MI:SS') AND PTIME >TO_DATE('20211001 00:00:00','yyyymmdd HH24:MI:SS')和用户沟通了一下，把以前的过期记录全部删除后来发现另外一张表EP_TABLE导出时也有坏块。即将导出指定的表通过常规路径 . . 正在导出表 EP_TABLEEXP-00056: ORACLE 错误 11

39、15 出现ORA-01115: 从文件 8 读取块时出现 IO 错误 (块 # 1200338)ORA-27070: skgfdisp: 异步读取/写入失败OSD-04016: 查询非同步 I/O 请求发生错误.O/S-Error: (OS 23) 数据错误 (循环冗余检查)。ORA-01115: 从文件 8 读取块时出现 IO 错误 (块 # 1200338)ORA-27070: skgfdisp: 异步读取/写入失败OSD-04016: 查询非同步 I/O 请求发生错误.O/S-Error: (OS 23) 数据错误 (循环冗余检查)。导出成功终止，但出现警告。同理处理。找到坏块所在记录的

40、时间段后exp时跳过。后面的恢复处理就不写了。特别注意：试过dbms_repair,但是dbms_repair找不到错误的记录。试过ALTER SYSTEM SET EVENTS '10231 trace name context forever,level 10' 也不能成功。奇怪了，只能猜硬盘坏的太厉害，产生了物理坏道。RMAN 可以备份包含损坏数据块的数据文件，通过设置 set maxcorrupt 可以跳过指定个数的坏块来防止备份失败。 RMAN> set maxcorrupt for datafile 1 to 10;在 Oracle9i中可以用 RMAN来执行

41、块级的恢复，而且恢复期间数据文件可以是联机状 态。RMAN通过 Block Media Recovery简称 BMR来执行块级恢复操作。假设我们在查 询一个 Oracle 表的时候接收到下面的错误：ERROR 位于第 1 行：ORA-01578： ORACLE 数据块损坏文件号 5，块号 97 ORA-01110： 数据文件 5： 'E：xxxx.dbf'那么我们就可以在 RMAN中用 BLOCKRECOVER 命令来修复：RMAN> BLOCKRECOVER DATAFILE 5 BLOCK97； 启动 blockrecover 于 03-9月 -06 正在启动全部恢复

42、目录的 resync完成全部 resync使用通道 ORA_DISK_1通道 ORA_DISK_1： 正在从数据文件副本 E：xxxx.bak 恢复块 正在开始介质的恢复完成介质的恢复完成 blockrecover 于 03-9月 -06块恢复 Block Media Recovery BMR，块是恢复的最小单元，通过块可以减少恢复 时间，而且数据文件可以在线。恢复块的时候，必须指定具体的块号，如：RMAN> blockrecoverdatafile 6 block 3；具体请见 4.7.4 块媒体恢复 Block Media Recovery BMR1指示RMAN从文件的备份集或映像副

43、本中复原与恢复一个指定的数据块： RMAN> blockrecover datafile 7 block 5;2BLOCKRECOVER命令可以接受假设干文件中的一列数据块： RMAN> blockrecover datafile 7 block 5,6,7 datafile 9 block 21,25;3从指定备份集中复原数据块 RMAN> blockrecover datafile 7 block 5 from backupset 1039;4从使用标记指定的备份中复原数据块 RMAN> blockrecover datafile 7 block 5 from ta

44、g monthly_whole;5使用至少已生成一周的备份来复原和恢复前一个备份操作发现受损的所有数据块： RMAN> blockrecover corruption list until time sysdate - 7;注意：此处关键字UNTIL并非表示不完全恢复！这个关键字意味着必须从特定日期序列号或SCN之前生成的备份中复原数据块。下面系统的总结一下坏块故障的处理：数据库出现坏块现象是指：在Oracle数据库的一个或多个数据块内出现内容混乱的现象。由于正常的数据块都有固定的合法内容格式，坏块的出现，导致数据库进程无法正常解析数据块的内容，进而使数据库进程报错乃至挂起，并级联导致整

45、个数据库实例出现异常。一坏块的产生原因坏块产生的原因大致有以下几种：1.1 硬件问题Oracle进程在处理一个数据块时，首先将其读入物理内存空间，在处理完成后，再由特定进程将其写回磁盘；如果在这个过程中，出现内存故障，CPU计算失误，都会导致内存数据块的内容混乱，最后反映到写回磁盘的数据块内容有误。同样，如果存储子系统出现异常，数据块损坏也就随之出现了。1.2 操作系统BUG由于Oracle进程对数据块的读写，都是以操作系统内核调用system call的方式完成的，如果操作系统在内核调用存在问题，必然导致Oracle进程写入非法的内容。1.3 操作系统的I/O错误或缓冲问题1.4 内存或pa

46、ging问题Oracle软件BUGOracle软件特定版本上，可能出现导致数据块的内容出现异常BUG。1.5 非Oracle进程扰乱Oracle共享内存区域如上文所述，在当数据块的内容被读入主机的物理内存时，如果其他非Oracle进程，对Oracle使用的共享内存区域形成了扰乱，最终导致写回磁盘的数据块内容混乱。1.6 异常关机，掉电，终止效劳异常关机，掉电，终止效劳使进程异常终止，而破坏数据块的完整性，导致坏块产生。注：这也是为什么突然断电会导致数据库无法启动由上可见，坏块的形成原因复杂。当出现坏块时，为了找到确切的原因，需要大量的分析时间和排查操作，甚至需要屡次重现才能找出根本原因。但当故

47、障发生在生产系统上，我们为了减少停机时间，会尽快实施应急权变措施以保证系统的可用性，这样就破坏了故障现场，对根本原因的分析因而也更加困难了。二坏块的预防坏块问题破坏性大，但并非不可预防。2.1 在Metalink.oracle 网站，Oracle定期发布基于特定软件版本的“问题(known issues)说明。对于可能导致坏块的Oracle软件BUG，在Oracle公司内部，是作为高严重级别的问题进行处理，在“问题(known issues)说明中，这些BUG以严重Noticable问题标出(标记为*或+)，局部问题，Oracle还会发布警告(Alert)通告。在文档中，Oracle会提供相应

48、的补丁或应对措施。2.2 Oracle提供备份恢复工具Recovery Manager，提供了扫描文件检查坏块的功能。在Recovery Manager界面中，使用：RMAN> BACKUP CHECK LOGICAL VALIDATE DATAFILE n ;可以检查数据文件是否包含坏块，同时并不产生实际的备份输出。2.3 Dbv工具检查注：因为dbv要求file后面跟的必须是一个文件扩展名，所以如果用裸设备存储的，就必须使用ln链接裸设备到一个文件，然后再用dbv对这个链接文件进行检查。ANALYZE TABLE tablename VALIDATE STRUCTURE CASCAD

49、E它执行坏块的检查，但是不会标记坏块为corrupt，检测的结果保存在USER_DUMP_DEST目录下的用户trace文件中。2.4 利用exp工具导出整个数据库可以检测坏块对以下情况的坏块是检测不出来的：HWM以上的坏块是不会发现的索引中存在的坏块是不会发现的数据字典中的坏块是不会发现的结合数据库性能综合考虑db_block_checksum和db_blockchecking参数。当我们使用Recovery Manager进行实际的数据库备份时，同时也就进行了坏块检查。但要注意的是，在线使用Recovery Manager扫描坏块和备份时，需要数据库运行在归档模式archive log，否

50、那么只能在数据库未翻开的情况下进行。对于操作系统问题和硬件故障，那么需要相应厂商的配合支持。同时，防止在数据库主机运行其他用户进程，防止异常停机，也会减少坏块发生的几率。三坏块故障的识别遇到坏块问题时，数据库的异常表现通常有：报告ORA-01578错误。报告Ora-1110错误。报告ORA-00600错误，其中，第一个参数为2000-8000，Cache layer 2000 4000，Transaction layer 4000 6000，Data layer 6000 - 8000。Trace文件中出现Corrupt block dba: 0x160c5958 . found。分析对象失败

51、。后台进程,如DBWR，LGWR出现长时间异常等待，如“LGWR wait for redo copy。四Oracle数据块损坏恢复总结可以用DBV 命令来检测是否有坏块：在恢复前使用DBV命令检查数据文件是否存在坏块dbv file=d:oracleoradatamydbRONLY.DBF blocksize=8192查看数据坏块所在数据文件号及块号可以对表进行一次全表扫描，如：select count(*) from tablename;关于DBV 命令的具体使用，请参考blog： :/4.1 没有备份的情况下：4.1.1、使用exp/imp恢复在这种情况下肯定会造成数据的丧失，在这种情况

52、下应采取将数据导出然后重建表再进行导入的方法，来尽量恢复损坏数据块中的数据，但是在有坏块的情况下是不允许导出的，如下命令：Exp test/test file=t.dmp tables=t;导出命令在执行中会报ORA-01578错误，在这错误提示中会提示那个文件号的文件以及这个文件中的哪个块被损坏，如：ORA01578：ORACLE 数据块损坏文件号 4，块号 35针对以上的提示首先查询那些对象被损坏：Select tablespace_name,segment_type,owner,segment_name From dba_extents Where file_id=4 and 35 be

53、tween block_id and block_id+blocks-1;如果被损坏的块是索引，通常可以通过索引重建来解决，如果损坏的是数据segment_type为table，那么通过设置如下内部事件使得Exp操作跳过坏块。Alter session set events='10231 trace name context forever,level 10'然后重新执行导出命令，导出相关的表，然后执行Drop Table命令删除相关表，之后重建表最后导入数据。4.1.2、使用DBMS_REPAIR恢复用DBMS_REPAIR当然也会丧失数据。这里不做详细的介绍，有兴趣的可以查

54、看oracle的在线文档4.2 使用Rman进行恢复：首先要存在Rman的备份集，然后执行如下命令：RMAN>backup validate datafile 4;检查4号数据文件是否存在坏块执行查询：select * from v$database_block_corruption where file#=4;如果4号文件存在坏块的话，那么将在结果集中有所显示，会显示损坏的块号，根据显示结果执行如下命令进行恢复：RMAN>blockrecover datafile 4 block 35 from backupset;该命令执行后即可恢复坏块，并且不会造成数据丧失，但是要求数据库必须要运行在归档模式下，否那么RMAN无法发挥作用，而且通过RMAN做过的数据库备份4.3 使用bbed恢复使用bbed恢复时必须有数据文件的拷贝。bbed就是英文block browse edit的缩写，用来直接查看和修改数据文件数据的一个工具。BBED在windows 8i中在$ORACLE_HOME/bin下可以找到，9i中似乎未随软件发布，故在windows没有这个工具，linux下需要编译，然后把$ORACLE_HOME/rdbms/lib加到环境变量的PATH里面，就可以直接在命令中bbed了。BBED的缺省口令为blockedit,For