分类: 服务器与存储
2008-06-16 20:21:41
前几天同事打电话过来,说公司的开发库每天死4,5次。正好今天回公司,顺道看了一下检查alertlog,发现成百上千的报错,全部是:
|
file#=22的文件是回滚段表空间中的一个数据文件,很明显回滚段数据块损坏了。
但是数据库还算能用,可以正常打开,但是无法正常关闭,
关闭的时候报:
|
然后整个实例就crash了。检查坏块所在的对象,发现是RBS01,再检查dba_rollback_segs视图,发现除了RBS01是online状态,其它的都是partitial available状态,手工将其余的回滚段online以后,就无法再次offline了,立刻有active的transaction占据回滚段,停掉了所有的其它会话,仍然是这种情况,查看v$trasaction视图,已经没有任何记录显示还有正在运行的事务了。
这种情况,无法正常地drop掉回滚段,自然也就没办法drop掉回滚段表空间。由于是开发库,根本就是处于非归档模式,也没有什么定时的备份,所以恢复数据库也不用想了。不过也好在是开发库,那些事务丢了也根本无所谓。于是,关闭数据库,修改初始化参数文件,添加隐含参数:
|
全部标志为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的表空间,再重新创建回滚段,没有问题了。(T004)