前几天同事打电话过来，说公司的开发库每天死4，5次。正好今天回公司，顺道看了一下检查alertlog，发现成百上千的报错，全部是：

Errors in file D:\oracle\admin\croot\bdump\crootSMON.TRC:
ORA-01578: ORACLE data block corrupted (file # 22, block # 14715)
ORA-01110: data file 22: 'D:\ORACLE\ORADATA\CROOT\TRBS1.ORA'

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

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

关闭的时候报：

Shutting down instance (immediate)
License high water mark = 90
Mon Oct 25 12:03:23 2004
ORACLE Instance croot (pid = 6) - Error 1578 encountered while 
recovering transaction (2, 50).
Mon Oct 25 12:03:23 2004
Errors in file D:\oracle\admin\croot\bdump\crootSMON.TRC:
ORA-01578: ORACLE data block corrupted (file # 22, block # 14715)
ORA-01110: data file 22: 'D:\ORACLE\ORADATA\CROOT\TRBS1.ORA'

然后整个实例就crash了。检查坏块所在的对象，发现是RBS01，再检查dba_rollback_segs视图，发现除了RBS01是online状态，其它的都是partitial available状态，手工将其余的回滚段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的数据文件，然后recover database；alter database open；数据库打开以后，再次检查v$rollname视图，发现只有SYSTEM表空间中的回滚段存在了，OK，再去dba_rollback_segs视图检查状态，发现除了SYSTEM回滚段其它的都处于need recover状态，好，没错。开始删除。

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

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

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