处理一个数据库坏块的问题，处理过程纪录如下：
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;
如果有坏块， 在扫描的时候就会报错