记录一次比较棘手数据库恢复要点
浏览:1704次 出处信息
在最近的一次数据库异常恢复过程中遇到不少问题,把重点记录下
ORA-00704/ORA-01555错误
Fri May 4 21:04:21 2012 select ctime, mtime, stime from obj$ where obj# = :1 Fri May 4 21:04:21 2012 Errors in file /oracle/admin/standdb/udump/perfdb_ora_1286288.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00604: error occurred at recursive SQL level 1 ORA-01555: snapshot too old: rollback segment number 40 with name "_SYSSMU40$" too small Error 704 happened during db open, shutting down database USER: terminating instance due to error 704 Instance terminated by USER, pid = 1286288 ORA-1092 signalled during: alter database open resetlogs... 这里的提示可以看出obj$基表中有事务存在,查询这个表的时候,要去找40号回滚段中相关数据;通过非常规方法, 查找到40号回滚段的状态是offliine了(这个查询出来的信息和是否使用隐含参数无关). 问题原因,为什么40号回滚段变得offline? Fri May 4 17:36:26 2012 alter tablespace undotbs offline Fri May 4 17:36:26 2012 ORA-1109 signalled during: alter tablespace undotbs offline... Fri May 4 17:37:29 2012 alter database datafile \'/dev/rundodbs01\' offline drop Fri May 4 17:37:29 2012 Completed: alter database datafile \'/dev/rundodbs01\' offline drop 因为强制offline 了file# 2文件导致(一个undo表空间文件) 解决方法: 1.bbed提交事务 因为现在生产的trace文件中未有关于obj$ 未提交事务的记录,做10046也为发现该记录,如果要使用bbed修改该事务, 那需要dump obj$相关的数据块(在mount状态下dump),然后找到相关事务,再修改 2.强制让file# 2 online 因为在resetlogs前file#2 已经offline掉了,所以要使得该文件能够成功online,需要先推进scn
ORA-00600[krhpfh_03-1209]
SQL> recover database until cancel; ORA-00283: recovery session canceled due to errors ORA-00600: internal error code, arguments: [krhpfh_03-1209], [2], [782415504], [782428968], [3987078030], [2379], [0], [0] ORA-01110: data file 2: \'/dev/rundodbs01\' 问题原因: 数据库处于非归档模式下,连续三次resetlogs,引起该bug 解决办法: 重建控制文件 但是这里问题出现了,因为file# 2的resetlogs scn和其他数据文件不一致,导致在file# 2 online的前提下,无法重建. 这样就处在了一个循环中(需要online file# 2 又要重建控制文件),这样的问题,可以通过bbed修改file# 2的resetlogs scn完成 或者先让file# 2 offline(没有加drop)掉,重建控制文件(除掉file# 2的文件记录)
ORA-00600[25025]
SMON: enabling cache recovery Fri May 4 22:36:36 2012 Errors in file /oracle/admin/standdb/udump/perfdb_ora_1167402.trc: ORA-00600: internal error code, arguments: [25025], [2], [], [], [], [], [], [] Fri May 4 22:36:38 2012 Errors in file /oracle/admin/standdb/udump/perfdb_ora_1167402.trc: ORA-00600: internal error code, arguments: [25025], [2], [], [], [], [], [], [] Fri May 4 22:36:38 2012 Error 600 happened during db open, shutting down database USER: terminating instance due to error 600 Instance terminated by USER, pid = 1167402 错误原因: 因为有undo文件不在undo对应的表空间中,而我们的file# 2文件确实是undo文件,而且重建控制文件时候未加入进来 解决办法: undo_management = AUTO undo_tablespace = UNDODBS(file# 2属于该表空间) 修改为 undo_management = MANUAL undo_tablespace = SYSTEM 或者bbed修改file# 2的header,然后重建控制文件
ORA-00600[4137]
Errors in file /oracle/admin/standdb/bdump/perfdb_smon_1290564.trc: ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], [] Fri May 4 23:20:52 2012 create undo tablespace undotbs3 datafile \'/dev/rundodbs21\' size 20400M Fri May 4 23:23:47 2012 Errors in file /oracle/admin/standdb/bdump/perfdb_smon_1290564.trc: ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], [] Fri May 4 23:23:48 2012 Errors in file /oracle/admin/standdb/bdump/perfdb_pmon_1520126.trc: ORA-00474: SMON process terminated with error Fri May 4 23:23:48 2012 PMON: terminating instance due to error 474 Instance terminated by PMON, pid = 1520126 错误原因: _smon_internal_errlimit(limit of SMON internal errors) SMON遇到了内部错误,最大允许100次, 不断计数增长,达到100的时候,数据库smon进程自动down掉,从而导致数据库down 解决办法: 1.临时解决办法:设置_smon_internal_errlimit一个较大值 3.根本解决办法:使用undo隐含参数,删除有问题undo 回滚段和undo表空间
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
扫一扫订阅我的微信号:IT技术博客大学习
<< 前一篇:oracle索引扫描
后一篇:如何正确安装ORACLE使ORACLE状态最优 >>
文章信息
- 作者:惜分飞 来源: 惜分飞
- 标签: 数据库恢复
- 发布时间:2012-05-12 22:38:57
近3天十大热文
- [3808] QR码分析
- [70] Twitter/微博客的学习摘要
- [67] IOS安全–浅谈关于IOS加固的几种方法
- [67] Go Reflect 性能
- [65] android 开发入门
- [65] 如何拿下简短的域名
- [65] find命令的一点注意事项
- [64] 流程管理与用户研究
- [62] 图书馆的世界纪录
- [61] 读书笔记-壹百度:百度十年千倍的29条法则