记断电引发的ORA-00600错误

接到同事的求助，先看了一下应用系统日志，问题已经指向了数据库并提示ORA-00600，登陆库所在服务器尝试startup 数据库失败，报ORA-00600ORA-00600，检查alert,找到最近时间点几个报错信息，查看后确认详细的报错在这里：

图片中的乱码是因为我的字符集问题，notepad+调了一下后显示就正常了。

Errors in file d:\app\administrator\diag\rdbms\his\his\trace\his_ora_3860.trc  (incident=4500380);

提示的具体信息是：ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [11571], [9900], [10091], [], [], [], [], [], [], [] 

继续查看tric文件的详细信息，找到路径下his_ora_3860.trc 显示如下：

trace文件说的很清楚了，应该是在实例恢复的时候（断电重启常见），用1 线程 11571 序列，恢复rba到9900，从rba 9900到rba 10091部分应该是损坏或者丢失了，从而导致数据库无法正常open。

解决问题：

把数据库启动到mount状态:

starup mount;

recover database;

ORA-00283:恢复会话因错误而取消

ORA-00264:不要求恢复

--oracle自己恢复不了，继续不完全恢复   RECOVER DATABASE UNTIL CANCEL;

ORA-10879:error signaled inparallel recovery slave

ORA-01547:警告: RECOVER 成功但 OPENRESETLOGS 将出现如下错误

ORA-01152:文件 1 没有从过旧的备份中还原

ORA-01110:数据文件 1: 'E:\app\Administrator\oradata\q**\SYSTEM01.DBF'

--再次失败，尝试恢复的过程中数据文件1，system01没能从旧的备份中还原回来，事情很棘手，想了两个思路，一是根据客户应用的断电时间确定一个时间点，检查这个时间段内oracle 的备份情况(我这台服务器正好有备份)做基于时间点的不完全恢复（需要应用系统日志配合，否则可能会丢数据的）。

rman>

 run 

 { 

 set until time "to_date('11/28/17 4:30:00','mm/dd/yy hh24:mi:ss')"; 

 restore database;

 recover database; 

 alter database open resetlogs;

 }

因为医院的系统日志里4:30就断了，9点才来了电，有了日志。这段时间内整个业务停顿，恢复成功后认真检查数据，确保没问题后再连应用系统给用户使用了。

第二个思路：我自己模拟了一遍重建控制文件

CREATE CONTROLFILE REUSE DATABASE "**his"NORESETLOGS NOARCHIVELOG

     MAXLOGFILES 16

     MAXLOGMEMBERS 3

     MAXDATAFILES 100

     MAXINSTANCES 8

     MAXLOGHISTORY 18688

    LOGFILE

    GROUP1'E:\app\Administrator\oradata\REDO01.LOG' SIZE 50M BLOCKSIZE 512,

    GROUP2'E:\app\Administrator\oradata\REDO02.LOG' SIZE 50M BLOCKSIZE 512,

    GROUP3'E:\app\Administrator\oradata\REDO03.LOG' SIZE 50M BLOCKSIZE 512

  DATAFILE

    'E:\app\Administrator\oradata\SYSTEM01.DBF',

    'E:\app\Administrator\oradata\SYSAUX01.DBF',

    'E:\app\Administrator\oradata\UNDOTBS01.DBF',

    'E:\app\Administrator\oradata\TABLESPACE01.DBF',

    'E:\app\Administrator\oradata\TABLESPACE02.DBF',

    'E:\app\Administrator\oradata\TABLESPACE03.DBF',

    'E:\app\Administrator\oradata\USERS01.DBF'

   CHARACTER SET ZHS16GBK ;

控制文件已创建。

RECOVER DATABSE

ALTER DATABASE OPEN;

数据库已更改。 模拟的环境毕竟不是原来的环境，按这个走了一遍，库跑起来了。想如果redo确实损坏了，那么还是得用不完全恢复，并以resetlogs方式打开。前后两个方法，根据实际情况，大家做参考吧。