oracle数据恢复后比对,记录一次比较棘手数据库恢复要点 – 提供7*24专业数据库(Oracle,SQL Server,MySQL等)恢复和Oracle技术服务@Tel:+86 134296487...

在最近的一次数据库异常恢复过程中遇到不少问题,把重点记录下

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 事件