1、使用DBV(DB File Verify)工具;
2、使用RMAN(Recovery Manager)工具;
DBV(DB File Verify)工具：外部命令，物理介质数据结构完整性检查；
只能用于数据文件（offline或online），不支持控制文件和重做日志文件的块检查；
也可以验证备份文件（rman的copy命令备份或操作系统CP命令备份）；
进入盘符，然后执行以下脚本:
D:\app\Administrator\oradata\orcl>dbv file=ZL9MTLBASE.DBF blocksize=8192;
逻辑数据结构完整性检查；
在线使用Recovery Manager扫描坏块和备份时，需要数据库运行在归档模式（archive log），否则只能在数据库未打开（mount）的情况下进行；
RMAN>backup check logical validate datafile n ;
以上命令可以检查数据文件是否包含坏块，同时并不产生实际的备份输出。
而且当使用Recovery Manager进行实际的数据库备份时，同时也就进行了坏块检查。
直接使用RMAN的命令：backup validate check logical database;
结合V$DATABASE_BLOCK_CORRUPTION视图更方便。
1)、rman target / nocatalog
2)、RMAN> spool log to 'd:/dbbak/rmanlog.log';---指定输出rman日志文件
RMAN> run { allocate channel d1 type disk; allocate channel d2 type disk; allocate channel d3 type disk; allocate channel d4 type disk; backup validate check logical database; };
3)、select * from V$DATABASE_BLOCK_CORRUPTION;
4) 、--If V$DATABASE_BLOCK_CORRUPTION contains rows please run this query to find the objects that contains the corrupted blocks:
SELECT e.owner,
e.segment_type,
e.segment_name,
e.partition_name,
c.file#,
greatest(e.block_id, c.block#) corr_start_block#,
least(e.block_id + e.blocks - 1, c.block# + c.blocks - 1) corr_end_block#,
least(e.block_id + e.blocks - 1, c.block# + c.blocks - 1) -
greatest(e.block_id, c.block#) + 1 blocks_corrupted,
null description
FROM dba_extents e, v$database_block_corruption c
WHERE e.file_id = c.file#
AND e.block_id = c.block#
UNION
SELECT s.owner,
s.segment_type,
s.segment_name,
s.partition_name,
c.file#,
header_block corr_start_block#,
header_block corr_end_block#,
1 blocks_corrupted,
'Segment Header' description
FROM dba_segments s, v$database_block_corruption c
WHERE s.header_file = c.file#
AND s.header_block between c.block# and c.block# + c.blocks - 1
UNION
SELECT null owner,
null segment_type,
null segment_name,
null partition_name,
c.file#,
greatest(f.block_id, c.block#) corr_start_block#,
least(f.block_id + f.blocks - 1, c.block# + c.blocks - 1) corr_end_block#,
least(f.block_id + f.blocks - 1, c.block# + c.blocks - 1) -
greatest(f.block_id, c.block#) + 1 blocks_corrupted,
'Free Block' description
FROM dba_free_space f, v$database_block_corruption c
WHERE f.file_id = c.file#
AND f.block_id = c.block#
order by file#, corr_start_block#;5)、
SELECT tablespace_name, segment_type, owner, segment_name FROM dba_extents WHERE file_id = &fileid and &blockid between block_id AND block_id + blocks - 1;
告警日志中快速识别：
遇到坏块问题时，数据库的异常表现通常有：
报告ORA-01578错误。
报告ORA-1110错误。
报告ORA-00600错误。其中，第一个参数为2000-8000，Cache layer 2000 – 4000，Transaction layer 4000 – 6000，Data layer 6000 - 8000。
Trace文件中出现Corrupt block dba: 0x160c5958 . found。 分析对象失败。
后台进程,如DBWR，LGWR出现长时间异常等待，如LGWR wait for redo copy。
修复数据库坏块 dbv你也可以用dbv工具看一下你现在其他的数据文件有没有还有坏块的
dbv file='yourfilename'恢复方法：
当Oracle数据库出现坏块时，Oracle会在警告日志文件（alert_SID.log（该文件位于：C:\app\Administrator\diag\rdbms\orcl\orcl\trace））中记录坏块的信息： ORA-01578: ORACLE data block corrupted (file # 7, block # ) ORA-01110: data file : '/oracle1/oradata/V920/oradata/V816/users01.dbf' 其中，＜AFN＞代表坏块所在数据文件的绝对文件号，代表坏块是数据文件上的第几个数据块 出现这种情况时，应该首先检查是否是硬件及操作系统上的故障导致Oracle数据库出现坏块。在排除了数据库以外的原因后，再对发生坏块的数据库对象进行处理。
1．确定发生坏块的数据库对象
SELECT tablespace_name,
segment_type,
owner,
segment_name
FROM dba_extents
WHERE file_id =
AND between block_id AND block_id+blocks-1;2．决定修复方法
如果发生坏块的对象是一个索引，那么可以直接把索引DROP掉后，再根据表里的记录进行重建； 如果发生坏块的表的记录可以根据其它表的记录生成的话，那么可以直接把这个表DROP掉后重建； 如果有数据库的备份，则恢复数据库的方法来进行修复； 如果表里的记录没有其它办法恢复，那么坏块上的记录就丢失了，只能把表中其它数据坏上的记录取出来，然后对这个表进行重建。
3．用Oracle提供的DBMS_REPAIR包标记出坏块
exec DBMS_REPAIR.SKIP_CORRUPT_BLOCKS('','');4．使用Create table as select命令将表中其它块上的记录保存到另一张表上
create table corrupt_table_bak
as
select * from corrupt_table;5．用DROP TABLE命令删除有坏块的表
drop table corrupt_table;6．用alter table rename命令恢复原来的表
alter table corrupt_table_bak
rename to corrupt_table;7．如果表上存在索引，则要重建表上的索引
PART22014.7.22研究恢复数据库坏块：
Oracle调用标准C的系统函数，对数据块进行读写操作，因此，坏块是有可能由以下几种原因产生：
硬件的I/O错误 操作系统的I/O错误或缓冲问题 内存或paging问题 磁盘修复工具 一个数据文件的一部分正在被覆盖 Oracle试图访问一个未被格式化的系统块失败 数据文件部分溢出 Oracle或者操作系统的bug
遇到“ORA-01578:ORACLE data block corrupted”错误 处理方法：1.rman的recover命令可以在数据库保持open状态下只恢复受损的数据块
2.如果没有备份，万不得已之下也可以采用DBMS_REPAIR包的存储过程将受损坏块隔离，同时尽可能地挽救部分数据。 rman backup命令也是检查坏数据块的好工具 一旦读取ORA-19566 即可有问题 此时可用backup validate tablespace user观察详细的信息，可查看到坏块数与跟踪文件 grep‘corrupt’/u01/app/oracle/diag/rdbms/br/br/trace/**.trc
恢复数据块：rman》recover datafile 5 block 203；
批量恢复受损的数据块：recover corruption list;
数据块坏块一号坏块，需要做：
run{
sql 'alter database datafile 5 offline';
restore datafile 5;
recover datafile 5;
sql'alter database datafile 5 online'
}1、使用exp/imp恢复
在这种情况下肯定会造成数据的丢失，在这种情况下应采取将数据导出然后重建表再进行导入的方法，来尽量恢复损坏数据块中的数据，但是在有坏块的情况下是不允许导出的，如下命令：Exp test/test file=t.dmp tables=t; 导出命令在执行中会报ORA-01578错误，在这错误提示中会提示那个文件号的文件以及这个文件中的哪个块被损坏，如：ORA—01578：ORACLE 数据块损坏（文件号 4，块号 35） 针对以上的提示首先查询那些对象被损坏：
Select
tablespace_name,segment_type,owner,segment_name
From dba_extents
Where file_id=4 and 35 between block_id and block_id+blocks-1;如果被损坏的块是索引，通常可以通过索引重建来解决，如果损坏的是数据（segment_type为table），那么通过设置如下内部事件使得Exp操作跳过坏块。
Alter session set events=’10231 trace name context forever,level 10’;然后重新执行导出命令，导出相关的表，然后执行Drop Table命令删除相关表，之后重建表最后导入数据。
2、使用DBMS_REPAIR恢复
用DBMS_REPAIR当然也会丢失数据。这里不做详细的介绍，有兴趣的可以查看oracle的在线文
3、使用dbms_repair包进行坏块处理
1）首先建立repair_table,用于存放dbms_repair.check_object检测出来的坏块信息
SQL> declare begin dbms_repair.admin_tables (table_name => 'REPAIR_TABLE',--表名 table_type => dbms_repair.repair_table, action => dbms_repair.create_action, tablespace => 'USERS');--用于指定该表存放的表空间 end; / PL/SQL 过程已成功完成。 SQL> col owner format a10 SQL> col object_name format a20 SQL> col object_type format a20 SQL> select owner, object_name, object_type from dba_objects where object_name like '%REPAIR_TABLE'; OWNEROBJECT_NAMEOBJECT_TYPE ---------- -------------------- -------------------- SYSREPAIR_TABLETABLE SYSDBA_REPAIR_TABLEVIEW Oracle自动创建了一个DBA_REPAIR_TABLE视图。2）使用dbms_repair.check_object进行坏块检测 SQL> set serveroutput on size 100000; SQL> declare rpr_count int; begin rpr_count := 0; dbms_repair.check_object( schema_name => 'SYS',--指定对象模式，也就是对象的所有者 object_name => 'TEST',--指定对象名，也就是表名 repair_table_name => 'REPAIR_TABLE', corrupt_count => rpr_count); dbms_output.put_line('repair block count: ' ||to_char(rpr_count)); end; / repair block count: 4 PL/SQL 过程已成功完成。 SQL> select object_name, block_id, corrupt_type, marked_corrupt, corrupt_description, repair_description from repair_table; OBJECT_NAMEBLOCK_ID CORRUPT_TYPE MARKED_COR -------------------- ---------- ------------ ---------- CORRUPT_DESCRIPTION ------------------------------------------------------------------------------- REPAIR_DESCRIPTION ------------------------------------------------------------------------------- TEST196148 TRUE mark block software corrupt TEST206148 TRUE mark block software corrupt TEST236148 TRUE mark block software corrupt TEST316148 TRUE mark block software corrupt 通过运行dbms_repair.check_object，将坏块信息存放到了repair_table表中，其中有个字段marked_corrupt，用于标识该块是否被标识为坏块，当被标识为true时，即该块被标识为坏块。其中这一步跟oracle文档中的描述有点进入，根据oracle文档，当执行完dbms_repair.check_object时，并不会进行坏块标识，也就是marked_corrupt列的值应该为false，而只有当执行dbms_repair.fix_corrupt_blocks过程后才会进行坏块标识。3）使用dbms_repair.fix_corrupt_blocks进行坏块标识 SQL> declare fix_block_count int; begin fix_block_count := 0; dbms_repair.fix_corrupt_blocks ( schema_name => 'SYS', object_name => 'TEST', object_type => dbms_repair.table_object, repair_table_name => 'REPAIR_TABLE', fix_count => fix_block_count); dbms_output.put_line('fix blocks count: ' || to_char(fix_block_count)); end; / fix blocks count: 0 PL/SQL 过程已成功完成。 我们可以见到到fix blocks count=0，即在上一步进行check_object时已经进行了坏块标识了，这一步其实可以省略。（不过没有测试过！）
转自：检查数据库坏块并处理_dba_monkey的博客-CSDN博客
