前几天同事打电话过来,说公司的开发库每天死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的表空间,再重新创建回滚段,没有问题了。
来源:博远电子(软件定制),如涉及版权问题请与我们联系。
TAG
软件定制,软件开发,瀚森HANSEN,辽宁,沈阳,抚顺