PostgreSQL 高级认证考试         PostgreSQL 中级认证考试(DBA 方向)         PostgreSQL 初级认证考试         EULER(欧拉)操作系统,見证RHCE的代表性!         19cOCP 9月周末班 正在授课 欢迎试听         RHCE9 9月周末班 正在授课 欢迎试学         PGCE 认证专家,周末班报名中,欢迎垂询         数据库运维工程师招聘         RHCE认证培训钜惠学习         OCP认证培训组团活动特惠中!!!         

如何处理Oracle数据库中的坏块问题

更新时间: 2016-09-30 02:50

本文主要介绍如何去处理在Oracle数据库中出现坏块的问题,对于坏块产生在不同的对象上,处理的方法会有所不同,本文将大致对这些方法做一些介绍。因为数据库运行时间长了,由于硬件设备的老化,出现坏块的几率会越来越大,因此,做为一个DBA,怎么去解决数据库出现的坏块问题就成了一个重要的议题了。
 
什么是数据库的坏块
首先我们来大概看一下数据库块的格式和结构
 
数据库的数据块有固定的格式和结构,分三层:cache layer,transaction layer,data layer。在我们对数据块进行读取写入操作的时候,数据库会对要读写的数据块做一致性的检查,其中包括:数据块的类型、数据块的地址信息、数据块的SCN号以及数据块的头部和尾部。如果发现其中有不一致的信息,那数据库就会标记这个数据块为坏块了。数据库的坏块分为两种,逻辑坏块和物理坏块。
 
坏块对数据库产生的影响
如果数据库出现坏块,数据库的告警日志文件里面会存在有如下的一些报错信息:Ora-1578以及Ora-600 and trace file in bdump directory,其中Ora-600错误的第一个参数值的范围是[2000]-[8000],不同的值代表着数据块的不同的层出现问题,具体的如下表所示:
Range                   block layer
Cache layer             2000 – 4000
Transaction layer       4000 – 6000
Data layer              6000 - 8000
 
坏块产生影响的对象可能是数据字典表、回滚段表、临时段、用户数据表和索引等。不同的对象产生坏块后的处理方法不尽相同。
 
坏块产生的原因
Oracle调用标准C的系统函数,对数据块进行读写操作,因此,坏块是有可能由以下几种原因产生:
 
  • 硬件的I/O错误
  • 操作系统的I/O错误或缓冲问题
  • 内存或paging问题
  • 磁盘修复工具
  •  一个数据文件的一部分正在被覆盖 
  • Oracle试图访问一个未被格式化的系统块失败
  • 数据文件部分溢出
  • Oracle或者操作系统的bug
 
坏块的处理方法
1.先收集相应的关于坏快的信息,从AlertSID.log文件或者从trace文件中查找,找到例如以下的一些信息:
Ora-1578  file#  (RFN)  block#
Ora-1110  file#  (AFN)  block#
Ora-600   file#  (AFN)  block#
 
其中RFN表示的是relative_fno
AFN表示的是file_id
 
Select file_name,tablespace_name,file_id “AFN”,relative_fno “RFN”
        
From dba_data_files;
        
Select file_name,tablespace_name,file_id, relative_fno“RFN”
        
From dba_temp_files;
 
2.确定存在坏块的对象是什么:
 SELECT tablespace_name, segment_type, owner, segment_name, partition_name  FROM dba_extents WHERE file_id = and between block_id AND block_id + blocks – 1;
 
通过上面这个查询语句就可以查出当前存在坏块的对象是什么,是什么类型的对象。需要注意的是如果是temp文件中出现坏块,是没有记录返回的。
 
3.根据2中查询出来的对象类型,确定相应的处理方法
 
出现坏块的常见对象有:
  • Sys用户下的对象
  • 回滚段
  • 临时段
  • 索引或者分区索引
 
常用的处理方法有:
  • 恢复数据文件
  • 只恢复坏的block(9i以上版本可用)
  • 通过ROWID RANGE SCAN 保存数据
  • 使用DBMS_REPAIR
  • 使用EVENT
 
4.具体处理方法的介绍
 
  • 恢复数据文件方法:
 
如果数据库是归档方式下,并且有完整的物理备份,就可以使用此方法来恢复。
 
步骤如下:
1)先offline受影响的数据文件,执行以下的语句: 
ALTER DATABASE DATAFILE 'name_file' OFFLINE;
 

 

2)保留有坏块的数据文件,然后拷贝备份的数据文件。如果恢复的数据文件要求路径不同,执行以下的语句:

ALTER DATABASE RENAME FILE 'old_name' TO 'new_name';
 

 

3) 恢复数据文件,执行以下语句:

RECOVER DATAFILE 'name_of_file';
 

 

4)Online恢复后的数据文件,执行以下的语句:

ALTER DATABASE DATAFILE 'name_of_file' ONLINE;
 
 
  • 只恢复坏的block(9i以上版本可用)
 
使用这种方法要求数据库版本是9.2.0以上,要求配置了Rman的catalog数据库,数据库为归档方式,并且有完整的物理备份。
 
步骤如下:
 
使用RMAN的BLOCKRECOVER命令 :
Rman>run{blockrecover datafile 5 block 11,16;}
 
也可以强制使用某个SCN号之前的备份,恢复数据块。
Rman>run{blockrecover datafile 5 block 11,16 restore until sequence 8505;}
 
 
  • 通过ROWID RANGE SCAN 保存数据
 
1) 先取得坏块中ROW ID的最小值,执行以下的语句:
SELECT dbms_rowid.rowid_create(1,,,,0) from DUAL;
 

 

2)取得坏块中的ROW ID的最大值,执行以下的语句:

SELECT dbms_rowid.rowid_create(1,,,+1,0) from DUAL;
 

 

3)建议一个临时表存储那些没有坏块的数据,执行以下的语句:

CREATE TABLE salvage_table AS SELECT  *   FROM  corrupt_tab Where 1=2;
 

 

4)保存那些不存在坏块的数据到临时表中,执行以下的语句:

INSERT INTO salvage_table SELECT /*+ ROWID(A) */ * FROM A WHERE rowid < '';
INSERT INTO salvage_table SELECT /*+ ROWID(A) */ * FROM A  WHERE rowid >= '‘;
 
 
5) 根据临时表中的数据重建表,重建表上的索引,限制。
 
  • 使用10231诊断事件,在做全表扫描的时候跳过坏块
 
可以在session级别设定:
ALTER SESSION SET EVENTS '10231 TRACE NAME CONTEXT FOREVER, LEVEL 10';
 

 

也可以在数据库级别上设定,在初始化参数中加入:event="10231 trace name context forever, level 10" ,然后重启数据库。

 
然后从存在坏块的表中取出不存在坏块的数据,执行以下的语句:
CREATE TABLE salvage_emp AS SELECT * FROM corrupt_table;
 
最后rename生成的corrupt_table为原来表的名字,并重建表上的索引和限制。
 
  • 使用dbms_repair包进行恢复
 
使用dbms_repair标记有坏块的表,在做全表扫描的时候跳过坏块,执行以下的语句:
 Execute DBMS_REPAIR.SKIP_CORRUPT_BLOCKS('','');
 
然后使用exp工具或者createtable as select的方法取出没有坏块数据,然后重建表,表上的索引和限制。
 
坏块的预先发现的方法
1.如果要检测数据库中所有的表,可以利用exp工具导出整个数据库可以检测坏块。不过这个工具有一些缺陷,对以下情况的坏块是检测不出来的:
  • HWM以上的坏块是不会发现的
  • 索引中存在的坏块是不会发现的
  • 数据字典中的坏块是不会发现的
 
2.如果只是对数据库中比较重要的表进行坏块检查,可以使用ANALYZE TABLE tablename VALIDATE STRUCTURE CASCADE 的方法来检测坏块,它执行坏块的检查,但是不会标记坏块为corrupt,检测的结果保存在USER_DUMP_DEST目录下的用户trace文件中。
 
3.使用Oracle的专门工具dbv来检查坏块,具体的语法如下:
关键字     说明                    (默认)
----------------------------------------------------
FILE        要验证的文件                 (无)
START       起始块                    (文件的第一个块)
END         结束块                      (文件的最后一个块)
BLOCKSIZE   逻辑块大小             (2048)
LOGFILE     输出日志                     (无)
FEEDBACK    显示进度               (0)
PARFILE     参数文件                 (无)
USERID      用户名/口令              (无)
SEGMENT_ID  段 ID (tsn.relfile.block) (无)
 
例如:
Dbv file=system01.dbf blocksize=8192
DBVERIFY: Release 9.2.0.5.0 - Production on 星期六 11月 27 15:29:13 2004
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
DBVERIFY - 验证正在开始 : FILE = system01.dbf
DBVERIFY - 验证完成
检查的页总数         :32000
处理的页总数(数据):13261
失败的页总数(数据):0
处理的页总数(索引):2184
失败的页总数(索引):0
处理的页总数(其它):1369
处理的总页数 (段)  : 0
失败的总页数 (段)  : 0
空的页总数            :15186
标记为损坏的总页数:0
汇入的页总数           :0
 
注:因为dbv要求file后面跟的必须是一个文件扩展名,所以如果用裸设备存储的,就必须使用ln链接裸设备到一个文件,然后再用dbv对这个链接文件进行检查。

开班信息MORE>>

课程名称 开课时间 上课类型 状态
OCP培训 12月 周末班 授课中...
RHCE培训 12月 周末班 授课中...
OCP培训 2025年1月 精英班 报名中...
PGCE 专家 12月 周末班 报名中...
OCM培训 12月 周末班 报名中...
RHCE培训 常年 周末班 报名中...
MySQL培训 常年 周末班 报名中...
<<