oracle三种类型坏块的处理思路总结(没有物理备份)

坏块的发生,很罕见,但生产系统偶尔还是会出现。如果有物理备份,处理起来相对简单,直接进行块级recover即可,但如果只有逻辑备份呢?处理起来要分四种情况,在此总结一下:


一、块的data部分坏了,在sql执行扫描到这个块的时候会报ORA-01578:

ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 21, block # 12)
ORA-01110: data file 21: ‘/u01/app/oracle/oradata/RWDB_production/T6.DBF‘


但是,这种坏块不会影响数据库重启,只是在重启到open阶段的时候会报:

Thu Nov 20 10:39:00 CST 2014
Corrupt Block Found
         TSN = 26, TSNAME = CORRUPT
         RFN = 21, BLK = 12, RDBA = 88080396
         OBJN = 591083, OBJD = 591083, OBJECT = USER_TAB, SUBOBJECT =
         SEGMENT OWNER = RWUSER, SEGMENT TYPE = Table Segment


db在open的时候会扫描数据文件的状态,这里可以清楚地看到是什么类型的段、什么用户、什么对象出现了坏块。还可以用dbv工具进一步check:

[oracle@BJ-TEST]/u01/app/oracle/admin/RWDB>dbv file=/u01/app/oracle/oradata/RWDB_production/T6.DBF


DBVERIFY - Verification complete

Total Pages Examined         : 25
Total Pages Processed (Data) : 0
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 11
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 13
Total Pages Marked Corrupt   : 1
Total Pages Influx           : 0
Highest block SCN            : 1132783081 (0.1132783081)

这里也可以清楚地看到Total Pages Marked Corrupt为1,即有1个坏块。


处理:

这种类型的坏块,处理办法有很多,support上的建议办法如下:

1、用DBMS_REPAIR.SKIP_CORRUPT_BLOCKS处理,即跳过坏块。

2、用CTAS建一个临时表,上面坏了的表为user_tab,可建一个临时表user_tab_tmp

3、将user_tab表重命名:alter table user_tab rename to user_tab_corrupt

4、将user_tab_tmp改为生产系统正式表:alter table user_tab_tmp rename to user_tab

5、重建user_tab表的索引

这种恢复办法,那个坏块里面的数据会丢掉。如果是每天都进行逻辑备份,还可以将现在的user_tab与昨天逻辑备份里面的user_tab进行比对,以最大限度恢复数据。


二、datafile的head块坏了(1号块)

一个8k block大小的数据文件,我们用ultraedit打开,以16进制方式显示,其中00000000~00001ff0是0号块,后面开始是1号块,即这个数据文件的head块。这个块坏了就相当危险,数据库重启会直接报错:

SQL> conn /as sysdba;
Connected to an idle instance.
SQL> startup;
ORACLE instance started.

Total System Global Area  935329792 bytes
Fixed Size                  2100680 bytes
Variable Size             385876536 bytes
Database Buffers          541065216 bytes
Redo Buffers                6287360 bytes
Database mounted.
ORA-01122: database file 24 failed verification check
ORA-01110: data file 24: ‘/u01/app/oracle/oradata/RWDB_production/T9.DBF‘
ORA-01210: data file header is media corrupt


可以看到,数据库打不开了。

alert报下面的东西:
Thu Nov 20 15:11:10 CST 2014
ALTER DATABASE OPEN
Read of rdba: 0x06000001 (file 24, block 1) failed with ORA-01210.
Hex dump of (file 24, block 1) in trace file /u01/app/oracle/admin/RWDB/udump/rwdb_ora_5850.trc
Corrupt block relative dba: 0x06000001 (file 24, block 1)
Bad header found during datafile header read
Data in bad block:
 type: 49 format: 1 rdba: 0x31000031
 last change scn: 0x0000.00000000 seq: 0x31 flg: 0x31
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x00000b01
 check value in block header: 0x3131
 block checksum disabled
Trying reread from disk.
Reread of rdba: 0x06000001 (file 24, block 1) failed with ORA-01210
ORA-1122 signalled during: ALTER DATABASE OPEN...


dbv也可以检测到:

[oracle@BJ-TEST]/u01/app/oracle/admin/RWDB/bdump>dbv file=/u01/app/oracle/oradata/RWDB_production/T9.DBF

DBVERIFY - Verification complete

Total Pages Examined         : 25
Total Pages Processed (Data) : 1
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 10
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 13
Total Pages Marked Corrupt   : 1
Total Pages Influx           : 0
Highest block SCN            : 1132794574 (0.1132794574)


如果半夜干升级割接(要重启服务器),遇到这种问题,身边又没有DBA,还是很棘手的,业务直接就会中断,如果是HA的系统,坏的datafile又刚好在磁阵上,那么通过切换也无法解决这个问题,因为oracle资源组就起不来。对于非归档模式的数据库,解决方法如下:

SQL> ALTER DATABASE DATAFILE ‘/u01/app/oracle/oradata/RWDB_production/T9.DBF‘ OFFLINE DROP;

Database altered.

SQL> alter database open;

Database altered.


这里,先不管数据丢失与否,先启动了数据库再说,免得故障闹大!:)


三、datafile的os head块坏了(0号块)

什么是datafile的0号块?官方称之为操作系统的头块,里面的东西不是oracle写的,是操作系统记录的文件大小等文件系统相关的信息。0号块坏了,可以正常重启数据库,没问题。但是,如果哪一天遇到紧急问题需要重建控制文件,将会面临报错:

ORA-27047: unable to read the header block of file


对于0号块的检测,用前面的dbv根本检测不出来(dbv命令貌似不检测0号块),需要用dbfsize来检测:

[oracle@BJ-TEST]/u02/backup>dbfsize /u01/app/oracle/oradata/RWDB_production/T8.DBF
/u01/app/oracle/oradata/RWDB_production/T8.DBF: Header block magic number is bad


这里会提示一个什么magic号坏了。

解决方法:

resize一下有问题的数据文件大小,os block head就会被重写,问题可以解决。

alter database datafile ‘/u01/app/oracle/oradata/RWDB_production/T8.DBF‘ resize <new size>


四、整个datafile都坏了(各种坏块的综合体)

笔者曾遇到过一次,整个文件都坏了,这种问题,可看做是以上坏块情况的集体爆发。

如:

dbvfile=/data1/app/oracle/oradata/RWDB/IRDBRoamerTS_01.dbf

Total Pages Examined         : 1926

Total Pages Processed (Data) : 0

Total Pages Failing   (Data) : 0

Total Pages Processed (Index): 0

Total Pages Failing   (Index): 0

Total Pages Processed (Other): 0

Total Pages Processed (Seg)  : 0

Total Pages Failing   (Seg) : 0

Total Pages Empty            : 0

Total Pages Marked Corrupt  : 1926

Total Pages Influx           : 0

Highest block SCN            : 0 (0.0)


这里可以看到,总共检测了1926个块,全坏了。如果遇到数据库重启,就无法open成功。

如果有RMAN备份,这种情况就很简单,直接restore、recover坏的数据文件就行。如果没有物理备份,就要先用上面第二种情况的解决办法先把数据库打开,然后再恢复数据。恢复数据的方法,与第二种里面又有所不同,既然这个文件里的块都坏了,再skip哪个块就没意义了。恢复数据的步骤如下:

1、看看这个dbf里面有哪些对象

2、用最新的逻辑备份将上面的对象impdp进新的表空间(如果IRDBRoamerTS_01不是表空间下的唯一文件,也可以不用建新的表空间)

本文出自 “数据库” 博客,请务必保留此出处http://weikle.blog.51cto.com/3324327/1582760

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。