联系:手机/微信(+86 17813235971) QQ(107644445)
作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
在最近的一次数据库异常恢复过程中遇到不少问题,把重点记录下
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表空间或者使用10513 事件