故障现象：
NetBackup备份出错，日志如下：
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ch01 channel at 06/15/2005 02:28:44
ORA-19566: 超出损坏块限制 0 (文件 /u01/app/oradata/unicom/system01.dbf)
故障分析：
由于事前发生过别的表空间(cookdbs：/u01/app/oradata/unicom/cokdbs.dbf)也有坏块的情况，根据李智他们的建议，使用迁移数据后删除表空间的办法解决(仅适用于普通表空间)。
这是查询该表空间上的表和索引对象的一个脚本：
GXdb% more query.sql
conn /as sysdba
col owner for a25
col segment_name for a40
spool table.log
select distinct OWNER,SEGMENT_NAME from dba_extents
where TABLESPACE_NAME='COOKDB'
and SEGMENT_TYPE='TABLE';
spool off
spool index.log
select distinct OWNER,SEGMENT_NAME from dba_extents
where TABLESPACE_NAME='COOKDB'
and SEGMENT_TYPE='INDEX';
spool off
exit
查询完毕后，使用一个迁移的脚本迁移到新的表空间：
GXdb% more move.sh
#!/bin/ksh
sqlplus /nolog @query.sql
NEWTBS="cookdbs1"
echo "conn /as sysdba" > move.sql
for TNAME in `cat table.log | awk '
/^COOKDB/ {print $2}
'`
do
echo "alter table cookdb.$TNAME move tablespace $NEWTBS;" >>move.sql
done
for INAME in `cat index.log | awk '
/^COOKDB/ {print $2}
'`
do
echo "ALTER INDEX cookdb.$INAME REBUILD TABLESPACE $NEWTBS;" >>move.sql
done
echo "exit" >>move.sql
sqlplus /nolog @move.sql
本次经过检查，发现包括有System在内的四个表空间的四个数据文件有坏块。为了能使用NetBackup备份，对NetBackup脚本做以下修改(对相应的数据文件设置maxcorrupt)：
run {
allocate channel ch00 type 'sbt_tape';
set maxcorrupt for datafile 1,27,28,44 to 10;
backup 。。。。。。
release channel ch00;
}
如果有归档日志没有丢失，都备份过，可以使用rman的blockrecover来修复文件的坏块，例如：
run {
allocate channel ch00 type 'sbt_tape';
blockrecover datafile 27 block 302089,302090,332823,332824,332825,332826;
blockrecover datafile 28 block 340846,340847,340848,340849;
blockrecover datafile 44 block 380381,380382,380383,380384,380405,380406,380407,380408;
blockrecover datafile 1 block 1703064,1703065,1703066,1703067,1703088,1703089,1703090,1703091;
release channel ch00;
}
但是中间由于备份失败，本地维护删除过归档日志。此方法不适用。
本次由于有SYSTEM表空间，不同于普通用户表空间，它有自己的特殊性。所以有些问题的解决方法也不尽相同。经多方探讨协商(Oracle India engineer、项目经理、本地维护、开发部门和系统工程部经理)，总结了以下处理办法：
解决SYSTEM表空间文件坏块的方法是导出全库数据，删除数据库，重建数据库，导入全库数据。具体的操纵步骤，经过讨论，见如下：主要是考虑到优化可以在线进行，也需要在线进行，还考虑到优化的万一出错性，既便出错至少还可以恢复到原始状态，如果优化没有成功，再做导出导入也不能恢复到初始状态。所以就先做导出导入工作再做优化处理。步骤是：
1. 导出整个数据库(数据库在线)，参考命令：exp system/manager file=/oraclebak/unicomdbfull.dmp full=Y log=/oraclebak/unicomfull.log
2. 备份配置文件 cp $ORACLE_HOME/dbs/* /Oraclebak，记录数据库名及实例名，参考字典视图V$DATABASE,V$INSTANCE
3. 删除数据库DBCA(/u02/app/oracle/product/9.2.0.1/bin/dbca)图形化配置工具。注意：建议不要删除数据文件、重做日志文件和控制文件以及归档日志文件，处理方法是：一)就数据文件、重做日志文件和控制文件分别改名为xxx.bak.xxx文件，例如mv datafile001.dbf datafile001.bak.dbf ;二)就归档日志文件，只改名归档日志文件所在的目录名即可，例如mv archivedir archivedirbak。要参考的数据字典视图有V$DATAFILE、V$LOGFILE、V$CONTROLFILE和archive log list 参数
4. 重建数据库DBCA(/u02/app/oracle/product/9.2.0.1/bin/dbca)图形化配置工具,
5. 导入整个数据库，imp system/unicom@unicom full=y ignore=y file=xxx.dmp log=yyy.log
6. 启动数据库，严格测试。
dbv file= /u02/app/oracle/oradata/unicom/system01.dbf blocksize=8192检查还有没有坏块。
7. 使用3.2SQL脚本检查表空间情况.
