■前几天同事打电话过来,说公司的开发库每天...... 前几天同事打电话过来,说公司的开发库每天死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的表空间,再重新创建回滚段,没有问题了。 |
|小黑屋|最新主题|手机版|微赢网络技术论坛 ( 苏ICP备08020429号 )
GMT+8, 2024-9-30 09:22 , Processed in 0.167055 second(s), 12 queries , Gzip On, MemCache On.
Powered by Discuz! X3.5
© 2001-2023 Discuz! Team.