数据库中的坏块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进去，否则这样恢复的数据库要使用的话会存在很大的风险。

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