数据库:数据库中的坏块ORA-01115,ORA-02072,ORA-01578

处理一个数据库坏块的问题，处理过程纪录如下：

 

1.根据报错的信息，用dbv确认一下，是否真的文件有坏块了，如果有，那继续，用下面的SQL查询出坏块为index还是数据，如果是索引，删除重建即可，如果是数据，那麻烦了，还要进行下一步动作。

SELECT SEGMENT_NAME, SEGMENT_TYPE FROM DBA_EXTENTS 
WHERE FILE_ID = <file_number> and <block_number> BETWEEN BLOCK_ID 
AND BLOCK_ID + BLOCKS - 1

2.在做这一步之前，先对数据所在的表进行备份，比如exp或者create newtable等等方法，注意第二种方法要把索引，约束等都备份出来。如果运气好的话，数据可以全部备份出来，那就简单了，将原表删除，重建，把数据弄进来即可；运气不好的话，某些数据还在坏区上不能导出，那就要使用事件10231跳过坏区，把好的数据先弄出来。SQL如下：

ALTER SYSTEM SET EVENTS ‘10231 trace name context forever,level 10’ 

然后再create new table或者exp来导出数据，注意导出完毕后用下列SQL把这个诊断事件关闭。

ALTER SYSTEM SET EVENTS ''10231 trace name context off ''  

3.步骤2运气不好就有可能会丢失数据，要保证数据不丢失，有三个办法：

A.   如果数据库的archive是全的，那就拿出表所在的数据文件最近一次的备份，用dbv检查一下，确认无坏块后，用它来恢复正式库的数据。步骤是"alter database datafile <file_name> offline"-->把坏的数据文件copy走-->拷贝备份文件过来-->"recover datafile <file_name>"-->"alter database datafile <file_name> online"。

B.   就是找负责AP的人员，根据表之间的数据关联关系来把丢失的数据拼出来。

C.   如果你是9i的数据库，用rman做的备份，rman中提供了一个指令，也可以从rman的备份中来恢复坏块，恢复时数据库可以是online的状态。指令如下：

blockrecover datafile <file_number> block  <block_number> from backupset;

4.其实上面的恢复动作也可作为system表空间的恢复，如果是undo某一个段坏掉了，可以使用下面的步骤：

A.   先备份建立rollbacksegment 的脚本(特别是Dictionary方式)，把监听器停掉，所有的session断开，看看v$transaction里面有没有活动的，如果有也删除掉。

B.   把数据库开在restrict模式下进行恢复，方法是尝试重新建立undo表空间和回滚段，建立完成，把回滚段online。

C.   确定数据库可以正常开启后，把旧的回滚段offline掉，旧的表空间删除。

       如果说数据库都打不开了，那就要使用备份的undo文件进行恢复，这样丢失数据最小。另外oracle提供了一个隐含参数"_corrupted_rollback_segments=（被损坏的段名）"，强制性的把数据库打开，不过这时数据库是在不一致的状态下，打开后赶快做一个数据库exp，重建数据库并imp进去，否则这样恢复的数据库要使用的话会存在很大的风险。

写了这么多，我发现怎么讲坏块给讲到数据库恢复里面去了。其实说起来坏块的处理只要备份工作做得好，还是挺容易解决的。大不了从备份中恢复一份出来，如果没有备份，那就要看运气了。

 

 

 

附： DBVERIFY工具的使用说明
DBVERIFY工具的主要目的是为了检查数据文件的物理结构，包括数据文件是否损坏，是否存在逻辑坏块，以及数据文件中包含何种类型的数据。

DBVERIFY工具可以验证ONLINE或OFFLINE的数据文件。不管数据库是否打开，都可以访问数据文件。

 

1.可以使用帮助查看dbv的命令参数

C:/>dbv help=y

DBVERIFY: Release 11.1.0.7.0 - Production on 星期二 12月 15 23:35:24 2009

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

关键字      说明                    (默认值)

----------------------------------------------------

FILE        要验证的文件                 (无)

START       起始块                    (文件的第一个块)

END         结束块                      (文件的最后一个块)

BLOCKSIZE   逻辑块大小             (8192)

LOGFILE     输出日志                     (无)

FEEDBACK    显示进度               (0)

PARFILE     参数文件                 (无)

USERID      用户名/口令              (无)

SEGMENT_ID  段 ID (tsn.relfile.block) (无)

HIGH_SCN    要验证的最高块 SCN    (无)

            (scn_wrap.scn_base 或 scn)

 

 

2.具体使用说明

DBVERIFY 验证数据文件
FILE 输入文件名
START 开始块地址
END 结束块地址
BLOCKSIZE 指定BLOCKSIZE尺寸
LOGFILE 指定LOG文件
FEEDBACK 进度显示
HELP 帮助
PARFILE 参数文件

3. 简单语法

3.1 dbv FILE=t_db1.dbf  FEEDBACK=100

 

E:/app/Administrator/oradata/orcl>dbv file=users01.dbf blocksize=8192

DBVERIFY: Release 11.1.0.7.0 - Production on 星期二 12月 15 23:54:55 2009

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

 

DBVERIFY - 开始验证: FILE = E:/app/Administrator/oradata/orcl/users01.dbf

 

 

DBVERIFY - 验证完成

检查的页总数: 640

处理的页总数 (数据): 91

失败的页总数 (数据): 0

处理的页总数 (索引): 33

失败的页总数 (索引): 0

处理的页总数 (其它): 496

处理的总页数 (段)  : 0

失败的总页数 (段)  : 0

空的页总数: 20

标记为损坏的总页数: 0

流入的页总数: 0

加密的总页数        : 0

最高块 SCN            : 904088 (0.904088)

 

注意目录，要进入数据文件的存放目录后在运行该命令，不然会报找不到数据文件。

 

3.2  DBV工具还有一种在数据库打开的情况下使用的，验证指定段的用法：

   dbv USERID=username/password SEGMENT_ID=tsn.relfile.block

DBVERIFY验证段
USERID 指定用户名和密码
SEGMENT_ID 指定验证的段
LOGFILE 指定LOG文件
FEEDBACK 进度显示
HELP 帮助
PARFILE 参数文件

 

这种方法需要查询表空间ID、段头所在的数据文件ID和以及段头所在表空间ID，要获取这个信息可以通过SYS用户查询SYS_DBA_SEGS视图。需要注意的是，Oracle文档给出的SYS_USER_SEGS视图只能查询SYS用户的段，要查询普通用户的段信息，需要访问SYS_DBA_SEGS。

ITPUB个人空间|*Ed

 

--------------------------------------------------------------------------------
B+pNj)_
SQL> create table DAVE (ID number);

表已创建。

SQL> SELECT TABLESPACE_ID, HEADER_FILE, HEADER_BLOCK FROM SYS_DBA_SEGS WHERE SEGMENT_NAME = 'DAVE';

TABLESPACE_ID HEADER_FILE HEADER_BLOCK

------------- ----------- ------------

            0           1        89976

E:/app/Administrator/oradata/orcl>dbv userid=system/admin segment_id=0.1.89976

 

DBVERIFY: Release 11.1.0.7.0 - Production on 星期三 12月 16 00:19:02 2009

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

DBVERIFY - 开始验证: SEGMENT_ID = 0.1.89976

DBVERIFY - 验证完成

 

检查的页总数: 9

处理的页总数 (数据): 0

失败的页总数 (数据): 0

处理的页总数 (索引): 0

失败的页总数 (索引): 0

处理的页总数 (其它): 9

处理的总页数 (段)  : 0

失败的总页数 (段)  : 0

空的页总数: 0

标记为损坏的总页数: 0

流入的页总数: 0

加密的总页数        : 0

最高块 SCN            : 912858 (0.912858)

 

注：这种方式要求数据库处于打开的状态。

 

4. 验证数据拷贝

由于dbv可以在实例关闭情况下验证数据文件，因此dbv也可以验证数据文件的拷贝。这个拷贝指的是通过RMAN的COPY命令或者操作系统命令cp拷贝的数据文件，而不是RMAN生成的备份集格式。

 

--------------------------------------------------------------------------------
E:/app/Administrator/oradata/orcl>dbv file= USERS01bak.DBF blocksize=8192

DBVERIFY: Release 11.1.0.7.0 - Production on 星期三 12月 16 00:30:17 2009

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

DBVERIFY - 开始验证: FILE = E:/app/Administrator/oradata/orcl/USERS01bak.DBF

DBVERIFY - 验证完成

检查的页总数: 640

处理的页总数 (数据): 91

失败的页总数 (数据): 0

处理的页总数 (索引): 33

失败的页总数 (索引): 0

处理的页总数 (其它): 496

处理的总页数 (段)  : 0

失败的总页数 (段)  : 0

空的页总数: 20

标记为损坏的总页数: 0

流入的页总数: 0

加密的总页数        : 0

最高块 SCN            : 904088 (0.904088)

 

 

一些注意事项：

1. 对于DBVERIFY工具，高版本可以自动识别低版本数据库，比如11g的dbv访问9i的数据库，但是低版本的dbv访问高版本会报如下之类的错误：

DBVERIFY -验证正在开始: FILE = e:/oracle/oradata/Dave/test01.dbf

汇入的页1 -可能是介质损坏

 

2. 查看数据坏块所在数据文件号及块号可以对表进行一次全表扫描，如：

select count(*) from tablename;

 

如果有坏块， 在扫描的时候就会报错