Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1204712
  • 博文数量: 1211
  • 博客积分: 10010
  • 博客等级: 上将
  • 技术积分: 14340
  • 用 户 组: 普通用户
  • 注册时间: 2008-06-09 11:20
文章分类

全部博文(1211)

文章存档

2011年(1)

2008年(1210)

我的朋友

分类: 服务器与存储

2008-06-16 20:21:41

 

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

阅读(727) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~