在数据库日常使用中，我们经常会遇到各种各样的坏块。 在不同文件中或不同对象中的损坏或坏块有着不同的处理方式。
控制文件损坏处理：
控制文件遇到坏块时，基本现象就是控制文件的损坏，数据库无法启动到 MOUNT，当然一般数据库都有多个控制文件组成。 如果遇到其中的一个或者几个控制文件损坏（不是全部控制文件损坏），那么我们可以通过修改 pfile 中的 control file 初始化参数去除损坏的控制文件，或者复制未损坏的控制文件来覆盖损坏的控制文件，来达到修复控制文件的目的。
如果遇到所有的控制文件损坏（没有做任何备份的情况下），那么就要我们手工来创建控制文件。
手工创建控制文件脚本列子如下（需要数据库在 nomount 下）：
CREATE CONTROLFILE REUSE DATABASE "orcl" RESETLOGS NOARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 \'/oradata/orcl/redo01.log\' SIZE 256M,
GROUP 2 \'/oradata/orcl/redo02.log\' SIZE 256M,
GROUP 3 \'/oradata/orcl/redo03.log\' SIZE 256M
DATAFILE
\'/oradata/orcl/SUPHISV3.dbf\',
\'/oradata/orcl/SUPHISV301.dbf\',
\'/oradata/orcl/SUPHISV302.dbf\',
\'/oradata/orcl/SUPHISV303.dbf\',
\'/oradata/orcl/SUPHISV304.dbf\',
\'/oradata/orcl/SUPHISV305.dbf\',
\'/oradata/orcl/SUPHISV3CJ.dbf\',
\'/oradata/orcl/SUPHISV3CJ01.dbf\',
\'/oradata/orcl/SUPHISV3CJ02.dbf\',
\'/oradata/orcl/SUPHISV3CJ03.dbf\',
\'/oradata/orcl/SUPNCIS.dbf\',
\'/oradata/orcl/SUPNCIS2011.dbf\',
\'/oradata/orcl/supncis01.dbf\',
\'/oradata/orcl/supncis02.dbf\',
\'/oradata/orcl/supncis03.dbf\',
\'/oradata/orcl/supncis04.dbf\',
\'/oradata/orcl/supncis05.dbf\',
\'/oradata/orcl/supncis06.dbf\',
\'/oradata/orcl/supncis07.dbf\',
\'/oradata/orcl/supncis08.dbf\',
\'/oradata/orcl/sysaux01.dbf\',
\'/oradata/orcl/system01.dbf\',
\'/oradata/orcl/undotbs01.dbf\',
\'/oradata/orcl/users01.dbf\'
CHARACTER SET ZHS16GBK;
注意上面脚本中标红的位置需要重点关注来进行修改。
orcl为数据库的SID
NORESETLOGS/RESETLOGS 为是否要重置 redo log 文件
NOARCHIVELOG/ARCHIVELOG 为数据库是否在归档模式
CHARACTER SET ZHS16GBK 为数据库的字符集
关于是否要重置 redo 需要根据具体情况进行判断：
一：对于在非归档模式下的数据库：
1) 当 redo log 文件为未损坏时，使用 noresetlogs noarchivelog
此时，当完成控制文件的创建后，直接使用
alter database mount;
alter database open;
可以直接打开数据库。
2) 当 redo log 文件也同样损坏，使用 resetlogs noarchivelog
alter database mount;
alter system set "_allow_resetlogs_corruption"=true scope=spfile; --这个参数是关键，可以允许Oracle重置REDO日志
recover database until cancel; --使用CANCEL退出，运行后才可以使用 resetlogs去open数据库
alter database open resetlogs;
二：对于在归档模式下的数据库：
1) 所有的 online logs 好的情况下，使用 noresetlogs archvelog
alter database mount;
alter system switch log all;
alter database open;
2) 如果 online logs 损坏，使用 resetlogs archivelog
对于至少有一个有效归档存在的环境（RAC 必须每个节点都有至少一个归档）
recover database using backup controlfile until cancle; --根据提示输入所需的归档文件的全路径
alter database open resetlogs;
对于没有归档存在的环境下
alter database mount;
alter system set "_allow_resetlogs_corruption"=true scope=spfile; --这个参数是关键，可以允许Oracle重置REDO日志
recover database until cancel; --使用CANCEL退出，运行后才可以使用 resetlogs去open数据库
alter database open resetlogs;
在上述各个情况下做完打开数据操作后，不要忘记添加 temp 表空间和做一次数据库全备。
当然可能还会遇到一些其他的报错信息，那么久需要对具体问题具体分析了。
Redo 文件损坏处理：
使用命令查看损坏的 redo log是不是当前的redo log，使用如下命令：
select group#,sequence#,archived,status from v$log;
一：非 current redo 损坏可进行删除，和重新添加的操作（注意至少有 2 组 redo log 文件），如:
ALTER DATABASE DROP LOGFILE GROUP 3;
Alter database add logfile thread 1 group 3 (‘/oradata/orcl/redo03.log’) size 256M;
二：current redo 损坏
1） 如果有归档和备份，可以用不完全恢复
startup mount;
recover database until cancel; --先选择auto，尽量恢复可以利用的归档日志，然后重新执行：
recover database until cancel; --这次输入cancel，完成不完全恢复, 用resetlogs打开数据：
alter database open resetlogs； --打开数据库
2） 强制恢复，这种方法可能会导致数据不一致
startup mount;
alter system set "_allow_resetlogs_corruption"=true scope=spfile;
recover database until cancel; --使用命令cancel
alter database open resetlogs;
一般强制恢复恢复后会有 undo segment 的问题。
一般操作为重建 undo 表空间，该步骤可在 undo 损坏中看到。
Undo 文件损坏处理：
Oracle 的 undo 有两种管理方式， 通过参数 undo_management 来设置 auto 和 manual。
1） 当 undo_management 被设置成 MENUAL 时使用系统回滚段, 即将 undo records 记录到 SYSTEM 表空间下的 SYSTEM 段。
SQL>select segment_name,tablespace_name,bytes,next_extent from dba_segments where segment_type=\'ROLLBACK\';
SEGMENT_NA TABLESPACE_NAME BYTES NEXT_EXTENT
------------------ -------------------------------- ------------------ ----------------------
SYSTEM SYSTEM 393216 1048576
通过上面的这条语句，我们查到了这个用于 rollback 的 system segment 存在与 system 表空间。默认情况下， 只有一个 segment， 并且它还比较小， 所以， 如果使用 system 段来存储 undo records。肯定会影响数据库的性能。所以Oracle是建议使用 Undo tablespace 来管理 undo records。
2） 当 undo_management 设置成 AUTO 时使用 UNDO tablespace 来管理回滚段。 这个 时候， 我们将有多个 undo segment， 并且这些 segment 是存放在 UNDO 表空间里的。 这 样对 DB 的性能就会提高。
SQL>select segment_name,tablespace_name,bytes,next_extent from dba_segments where segment_type=\'TYPE2 UNDO\';
SEGMENT_NAME TABLESPACE_NAME BYTES NEXT_EXTENT
-------------------- -------------------- ---------- -----------
_SYSSMU1$ UNDOTBS1 1179648 65536
_SYSSMU2$ UNDOTBS1 1179648 65536
_SYSSMU3$ UNDOTBS1 2228224 65536
_SYSSMU4$ UNDOTBS1 1179648 65536
_SYSSMU5$ UNDOTBS1 262144 65536
_SYSSMU6$ UNDOTBS1 1179648 65536
_SYSSMU7$ UNDOTBS1 1179648 65536
_SYSSMU8$ UNDOTBS1 1179648 65536
_SYSSMU9$ UNDOTBS1 1179648 65536
_SYSSMU10$ UNDOTBS1 1179648 65536
通过以上 SQL 的查询结果， 我们可以看出， 有 10 个 undo segment 来存放 undo records。
以上我们是通过 dba_segment 表查看的结果。 也可以通过 v$rollstat 和 v$rollname 两个视图来查看信息。这 2 个视图会显示所有 rollback 段的信息。包括 system 段和 undo 段。
SQL> col name format a15
SQL> select s.usn,n.name,s.extents,s.hwmsize,s.status from v$rollstat s, v$rollname n where s.usn=n.usn;
USN NAME EXTENTS HWMSIZE STATUS
---------- --------------- ---------- ---------- ---------------
0 SYSTEM 6 385024 ONLINE
1 _SYSSMU1$ 3 7659520 ONLINE
2 _SYSSMU2$ 3 9691136 ONLINE
3 _SYSSMU3$ 4 7462912 ONLINE
4 _SYSSMU4$ 3 76668928 ONLINE
5 _SYSSMU5$ 4 8511488 ONLINE
6 _SYSSMU6$ 3 7462912 ONLINE
7 _SYSSMU7$ 3 33480704 ONLINE
8 _SYSSMU8$ 3 8577024 ONLINE
9 _SYSSMU9$ 3 7462912 ONLINE
10 _SYSSMU10$ 3 13754368 ONLINE
11 rows selected.
3） UNDO 损坏的情况
出现这种情况，大多数是因为异常宕机，在启动的时候报的错误。DB 不能启动。
比如：ORA-00600: internal error code, arguments: [4194],
对于 Undo 损坏的情况，能用备份恢复最好，如果不能，就只能通过一些特殊的方 法来恢复。
方法一：使用 system segment 步骤如下： （
1）用 spfile 创建 pfile，然后修改参数：
#*.undo_tablespace=\'UNDOTBS1\'
#*.undo_management=\'AUTO\'
#*.undo_tablespace
#*.undo_retention
undo_management=\'MANUAL\'
rollback_segments=\'SYSTEM\'
（2）用修改之后的 pfile，重启 DB
SQL> STARTUP MOUNT pfile=\'/oracle/product/10.2.0/dbs/initorcl.ora\' ;
（3）删除原来的表空间，创建新的 UNDO 表空间
SQL> drop tablespace undotbs;
SQL> create undo tablespace undotbs1 datafile \'/u01/oradata/undotbs1.dbf\' size 10M;
（4）关闭数据库，修改 pfile 参数，然后用新的 pfile 创建 spfile，在正常启动数据库。
*.undo_tablespace=\'UNDOTBS1\'
*.undo_management=\'AUTO\'
#undo_management=\'MANUAL\'
#rollback_segments=\'SYSTEM\'
方法二：跳过损坏的 segment 在方法一里面，使用了 system segment。undo segment 一般有多个，我们可以 通过 alert log 来查看正在使用的是哪些 segment，这些段有可能损坏了。那么只需要把这些损坏的 segment 跳过，先正常启动 DB，在创建新的 UNDO 表空间，在切换一下。
（1）修改 pfile，添加参数：
*._corrupted_rollback_segments=\'_SYSSMU11$\',\'_SYSSMU12$\',\'_SYSSM U13$\'
这些字段的值，我们通过 alert log 查看。 也可以通过如下命令查看：
#strings system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort -u
（2）用修改之后的 pfile 启动 DB
因为跳过了哪些损坏的 segment，所以 DB 可以正常启动。
（3）创建新的 UNDO 表空间，并切换过来
SQL> create undo tablespace undotbs1 datafile
\'/u01/oradata/undotbs1.dbf\' size 10M;
SQL> alter system set undo_tablespace=undotbs1;
SQL> drop tablespace undotbs;
（4）修改 pfile，创建 spfile，并正常启动
删除：
*._corrupted_rollback_segments=\'_SYSSMU11$\',\'_SYSSMU12$\',\'_SYSSM U13$\'
SQL> select segment_name,status from dba_rollback_segs ; rollback_segment --查看
此时回滚段状态为offline，现在都可以删除了：
SQL> drop rollback segment "_SYSSMU11$" ;
SQL> drop rollback segment "_SYSSMU12$" ;
SQL> drop rollback segment "_SYSSMU13$" ;
DATAFILE 坏块处理
一：什么是数据库的坏块数据库的数据块有固定的格式和结构，分三层：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 = <AFN> and <BL> 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,<OBJ_ID>,<RFN>,<BL>,0) from DUAL;
2）取得坏块中的 ROW ID 的最大值，执行以下的语句：
SELECT dbms_rowid.rowid_create(1,<OBJ_ID>,<RFN>,<BL>+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 <owner.tablename> A WHERE rowid < \'<low_rid>\'；
INSERT INTO salvage_table SELECT /*+ ROWID(A) */ * FROM <owner.tablename> A WHERE rowid >= \'<hi_rid>\';
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(\'<schema>\',\'<tablename>\');
然后使用导入导出工具或者 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 对这个链接文件进行 检查。