正好今天回公司，顺道看了一下

检查alertlog，发现成百上千的报错，全部是：

errorsinfiled:\oracle\admin\croot\bdump\crootsmon.trc:
ora-01578:oracledatablockcorrupted(file#22,block#14715)
ora-01110:datafile22:’d:\oracle\oradata\croot\trbs1.ora’


file#=22的文件是回滚段表空间中的一个数据文件，很明显回滚段数据块损坏了。

但是数据库还算能用，可以正常打开，但是无法正常关闭，

关闭的时候报：


shuttingdowninstance(immediate)
licensehighwatermark=90
monoct2512:03:232004
oracleinstancecroot(pid=6)-error1578encounteredwhile
recoveringtransaction(2,50).
monoct2512:03:232004
errorsinfiled:\oracle\admin\croot\bdump\crootsmon.trc:
ora-01578:oracledatablockcorrupted(file#22,block#14715)
ora-01110:datafile22:’d:\oracle\oradata\croot\trbs1.ora’


然后整个实例就crash了

检查坏块所在的对象，发现是rbs01，再检查dba_rollback_segs视图，发现除了rbs01是online状态，其它的都是partitialavailable状态，手工将其余的回滚段online以后，就无法再次offline了，立刻有active的transaction占据回滚段，停掉了所有的其它会话，仍然是这种情况，查看v$trasaction视图，已经没有任何记录显示还有正在运行的事务了。

这种情况，无法正常地drop掉回滚段，自然也就没办法drop掉回滚段表空间。

由于是开发库，根本就是处于非归档模式，也没有什么定时的备份，所以恢复数据库也不用想了。

不过也好在是开发库，那些事务丢了也根本无所谓。

于是，关闭数据库，修改初始化参数文件，添加隐含参数：


_corrupted_rollback_segments=(rbs1,rbs2,rbs4,rbs5,rbs6,rbs7,rbs8,rbs9,rbs10)


全部标志为corrupted的，然后启动数据库到mount状态

drop掉file#=22的数据文件

然后recoverdatabase；alterdatabaseopen；

数据库打开以后，再次检查v$rollname视图，发现只有system表空间中的回滚段存在了，ok，再去dba_rollback_segs视图检查状态，发现除了system回滚段其它的都处于needrecover状态，好，没错。开始删除。

直接drop掉所有的回滚段，drop掉回滚段表空间，然后创建新的表空间，创建新的回滚段，将所有回滚段online，中间出了个小插曲，后面提到。

最后，正常关闭数据库，修改init参数，将_corrupted_rollback_segments这行注释掉，最后正常启动数据库。随便找几张表，作几个insert测试了一下，没有问题，ok，修复完成。

小插曲：创建新的回滚段时出了一个问题，耽误了一段时间，因为是8i的库，system表空间是dmt的，所以回滚段表空间也必须是dmt的，开始按照习惯创建了一个lmt的表空间，然后创建回滚段的时候总是报错，说非系统回滚段无法使用system表空间，想了好一阵，才想起dmt和lmt的这回事儿，然后drop掉新建的lmt表空间，创建了一个dmt的表空间，再重新创建回滚段，没有问题了。
前几天同事打电话过来，说公司的开发库每天死4，5次

正好今天回公司，顺道看了一下

检查alertlog，发现成百上千的报错，全部是：


errorsinfiled:\oracle\admin\croot\bdump\crootsmon.trc:
ora-01578:oracledatablockcorrupted(file#22,block#14715)
ora-01110:datafile22:’d:\oracle\oradata\croot\trbs1.ora’


file#=22的文件是回滚段表空间中的一个数据文件，很明显回滚段数据块损坏了。

但是数据库还算能用，可以正常打开，但是无法正常关闭，

关闭的时候报：


shuttingdowninstance(immediate)
licensehighwatermark=90
monoct2512:03:232004
oracleinstancecroot(pid=6)-error1578encounteredwhile
recoveringtransaction(2,50).
monoct2512:03:232004
errorsinfiled:\oracle\admin\croot\bdump\crootsmon.trc:
ora-01578:oracledatablockcorrupted(file#22,block#14715)
ora-01110:datafile22:’d:\oracle\oradata\croot\trbs1.ora’


然后整个实例就crash了

检查坏块所在的对象，发现是rbs01，再检查dba_rollback_segs视图，发现除了rbs01是online状态，其它的都是partitialavailable状态，手工将其余的回滚段online以后，就无法再次offline了，立刻有active的transaction占据回滚段，停掉了所有的其它会话，仍然是这种情况，查看v$trasaction视图，已经没有任何记录显示还有正在运行的事务了。

这种情况，无法正常地drop掉回滚段，自然也就没办法drop掉回滚段表空间。

由于是开发库，根本就是处于非归档模式，也没有什么定时的备份，所以恢复数据库也不用想了。

不过也好在是开发库，那些事务丢了也根本无所谓。

于是，关闭数据库，修改初始化参数文件，添加隐含参数：


_corrupted_rollback_segments=(rbs1,rbs2,rbs4,rbs5,rbs6,rbs7,rbs8,rbs9,rbs10)


全部标志为corrupted的，然后启动数据库到mount状态

drop掉file#=22的数据文件

然后recoverdatabase；alterdatabaseopen；

数据库打开以后，再次检查v$rollname视图，发现只有system表空间中的回滚段存在了，ok，再去dba_rollback_segs视图检查状态，发现除了system回滚段其它的都处于needrecover状态，好，没错。开始删除。

直接drop掉所有的回滚段，drop掉回滚段表空间，然后创建新的表空间，创建新的回滚段，将所有回滚段online，中间出了个小插曲，后面提到。

最后，正常关闭数据库，修改init参数，将_corrupted_rollback_segments这行注释掉，最后正常启动数据库。随便找几张表，作几个insert测试了一下，没有问题，ok，修复完成。

小插曲：创建新的回滚段时出了一个问题，耽误了一段时间，因为是8i的库，system表空间是dmt的，所以回滚段表空间也必须是dmt的，开始按照习惯创建了一个lmt的表空间，然后创建回滚段的时候总是报错，说非系统回滚段无法使用system表空间，想了好一阵，才想起dmt和lmt的这回事儿，然后drop掉新建的lmt表空间，创建了一个dmt的表空间，再重新创建回滚段，没有问题了。