IDC资讯中心
前几天同事打电话过来，说公司的开发库每天死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的表空间，再重新创建回滚段，没有问题了。
