我的Oracle数据库又打不开了，碰到了ORA-00600:[kcratr_nab_less_than_odr]

skylines 2023-05-15

125

在昨天，我想登陆我的Oracle数据库想进行一个测试，因为早之前，在上面创建过一个测试表，而且我手中就一个Oracle测试环境，我得必须用它，却发现打不开了。居然报了ora-600，最让Oracle DBA不想看到的报错号。然后我再详细看了报错信息，发现问题不大，就是数据库由于突然掉电，出现了redo日志写出错的问题，需要打开的话，就需要进行不完全恢复，“有可能”丢失一些数据。当然啦，我的测试环境，很久时间没怎么写数据进去了，不会存在丢失什么数据了。当然，如果是在线的生产环境，如果存在掉电关库，出现了这种ora-600，redo日志损坏的情况，也是挺头疼的，一个影响生产业务，另一个就是存在丢失业务数据的风险，再一个就是可能花上一些时间去打开数据库。

这台测试环境放在我的笔记本电脑虚拟机上，笔记本最近两个月，我一直开着，中间会暂停一下虚拟机。我的笔记本电脑呢，晚上我都会拔掉电源，让它自己利用剩余的电量“过夜”。这次，也是第二次出现redo日志写出错的问题了，那这次进行打开数据库，问题就不大了。我的操作过程如下：

1、尝试登陆数据库报错

[oracle@susource ~]$ ps -ef |grep smon
oracle    20667  20617  0 18:21 pts/1    00:00:00 grep --color=auto smon
[oracle@susource ~]$ 
[oracle@susource ~]$ 
[oracle@susource ~]$ sqlplus  as sysdba




SQL*Plus: Release 11.2.0.4.0 Production on Sat May 13 18:21:20 2023




Copyright (c) 1982, 2013, Oracle.  All rights reserved.




Connected to an idle instance.




SQL> 
SQL> startup
ORACLE instance started.




Total System Global Area  759943168 bytes
Fixed Size                  2257112 bytes
Variable Size             465571624 bytes
Database Buffers          289406976 bytes
Redo Buffers                2707456 bytes
Database mounted.
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1],
[119], [60869], [61194], [], [], [], [], [], [], []

查询告警日志alter和trace文件,对照上网查询错误，获取报错原因：

由于服务器异常短电，导致LGWR写联机日志文件时失败，下次重新启动数据库时，需要做实例级恢复，而又无法从联机日志文件里获取到这些redo信息，因为上次断电时，写日志失败了。

2、登陆MOS查看报错内容

解决方法有两种，我采用了第一种，如下截图，具体查看具体文档地址。

MOS地址：Alter database open fails with ORA-00600 kcratr_nab_less_than_odr (Doc ID 1296264.1)

3、查看文件系统并查看归档日志

SQL> 
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@susource ~]$ 


[oracle@susource ~]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3        28G   26G  2.4G  92% 
devtmpfs        898M     0  898M   0% dev
tmpfs           912M   92M  821M  11% dev/shm
tmpfs           912M   17M  895M   2% run
tmpfs           912M     0  912M   0% sys/fs/cgroup
/dev/sda1       297M  152M  146M  51% boot
tmpfs           183M   16K  183M   1% run/user/42
tmpfs           183M     0  183M   0% run/user/0
[oracle@susource ~]$


[oracle@susource ~]$ cd u01/app/oracle/arch/
[oracle@susource arch]$ 
[oracle@susource arch]$ 
[oracle@susource arch]$ ls -lrt
total 2016456
-rw-r--r-- 1 oracle oinstall 25555810 Mar  9  2022 mysource.ora
-rw-r----- 1 oracle oinstall 28583936 Mar 20  2022 1_72_1098480796.dbf
-rw-r----- 1 oracle oinstall 13366784 Mar 20  2022 1_73_1098480796.dbf
-rw-r----- 1 oracle oinstall 50049536 Mar 23  2022 1_74_1098480796.dbf
-rw-r----- 1 oracle oinstall 50049536 Mar 27  2022 1_75_1098480796.dbf
-rw-r----- 1 oracle oinstall 50046976 Mar 28  2022 1_76_1098480796.dbf
-rw-r----- 1 oracle oinstall 43178496 Mar 28  2022 1_77_1098480796.dbf
-rw-r----- 1 oracle oinstall 50049536 Apr  7  2022 1_78_1098480796.dbf
-rw-r----- 1 oracle oinstall 32734720 Apr  8  2022 1_79_1098480796.dbf
-rw-r----- 1 oracle oinstall     8192 Apr  8  2022 1_80_1098480796.dbf
-rw-r----- 1 oracle oinstall 48353792 Apr  9  2022 1_81_1098480796.dbf
-rw-r----- 1 oracle oinstall 46637056 Apr  9  2022 1_82_1098480796.dbf
-rw-r----- 1 oracle oinstall 42775552 Apr 10  2022 1_83_1098480796.dbf
-rw-r----- 1 oracle oinstall 42792448 Apr 11  2022 1_84_1098480796.dbf
-rw-r----- 1 oracle oinstall 42776576 Apr 15  2022 1_85_1098480796.dbf
-rw-r----- 1 oracle oinstall 42776064 Apr 17  2022 1_86_1098480796.dbf
-rw-r----- 1 oracle oinstall 50049536 Apr 20  2022 1_87_1098480796.dbf
-rw-r----- 1 oracle oinstall 45241344 Apr 20  2022 1_88_1098480796.dbf
-rw-r----- 1 oracle oinstall 46093312 Apr 20  2022 1_89_1098480796.dbf
-rw-r----- 1 oracle oinstall 50049536 May  5  2022 1_90_1098480796.dbf
-rw-r----- 1 oracle oinstall 50041856 May  7  2022 1_91_1098480796.dbf
-rw-r----- 1 oracle oinstall 43447808 May  7  2022 1_92_1098480796.dbf
-rw-r----- 1 oracle oinstall 43485696 May  8  2022 1_93_1098480796.dbf
-rw-r----- 1 oracle oinstall 48416768 May 10  2022 1_94_1098480796.dbf
-rw-r----- 1 oracle oinstall 44252672 May 10  2022 1_95_1098480796.dbf
-rw-r----- 1 oracle oinstall 42786816 May 15  2022 1_96_1098480796.dbf
-rw-r----- 1 oracle oinstall 44180480 May 19  2022 1_97_1098480796.dbf
-rw-r----- 1 oracle oinstall 50049536 May 19  2022 1_98_1098480796.dbf
-rw-r----- 1 oracle oinstall 42776064 May 20  2022 1_99_1098480796.dbf
-rw-r----- 1 oracle oinstall 42775552 May 22  2022 1_100_1098480796.dbf
-rw-r----- 1 oracle oinstall 42775552 May 23  2022 1_101_1098480796.dbf
-rw-r----- 1 oracle oinstall 45186560 May 30  2022 1_102_1098480796.dbf
-rw-r----- 1 oracle oinstall 50049536 May 30  2022 1_103_1098480796.dbf
-rw-r----- 1 oracle oinstall 44888576 May 30  2022 1_104_1098480796.dbf
-rw-r----- 1 oracle oinstall 45632512 May 31  2022 1_105_1098480796.dbf
-rw-r----- 1 oracle oinstall 43494400 Jun  2  2022 1_106_1098480796.dbf
-rw-r----- 1 oracle oinstall 50842112 Aug 15  2022 1_107_1098480796.dbf
-rw-r----- 1 oracle oinstall 50049536 Aug 15  2022 1_108_1098480796.dbf
-rw-r----- 1 oracle oinstall 44864512 Aug 31  2022 1_109_1098480796.dbf
-rw-r----- 1 oracle oinstall 50041856 Aug 31  2022 1_110_1098480796.dbf
-rw-r----- 1 oracle oinstall 50049536 Feb  8 18:02 1_111_1098480796.dbf
-rw-r----- 1 oracle oinstall 50047488 Feb  8 22:01 1_112_1098480796.dbf
-rw-r----- 1 oracle oinstall 42776064 Feb  8 23:56 1_113_1098480796.dbf
-rw-r----- 1 oracle oinstall 43093504 Feb 11 19:17 1_114_1098480796.dbf
-rw-r----- 1 oracle oinstall 44197376 Feb 12 18:05 1_115_1098480796.dbf
-rw-r----- 1 oracle oinstall 26978816 Feb 21 18:29 1_116_1098480796.dbf
-rw-r----- 1 oracle oinstall 43191808 Feb 21 22:00 1_117_1098480796.dbf
-rw-r----- 1 oracle oinstall 43197440 Feb 21 22:01 1_118_1098480796.dbf

--可以知道，后台还没有完成序列为119号的归档日志。

4、尝试直接进行恢复

[oracle@susource ~]$ sqlplus  as sysdba




SQL*Plus: Release 11.2.0.4.0 Production on Sat May 13 18:23:30 2023




Copyright (c) 1982, 2013, Oracle.  All rights reserved.








Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options




SQL> 
SQL> 
SQL> select instance_name,status from v$instance;




INSTANCE_NAME    STATUS
---------------- ------------
mysource         MOUNTED




SQL> 
SQL> 
SQL> RECOVER DATABASE ;
Media recovery complete.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1],
[119], [60869], [61194], [], [], [], [], [], [], []








SQL> select instance_name,status from v$instance;




INSTANCE_NAME    STATUS
---------------- ------------
mysource         MOUNTED




SQL>

--直接恢复还是失败。

5、根据上述MOS方法进行恢复redo日志的数据

SQL> select group#,sequence#,status,first_time,next_change# from v$log;




    GROUP#  SEQUENCE# STATUS           FIRST_TIM NEXT_CHANGE#
---------- ---------- ---------------- --------- ------------
         1        118 INACTIVE         21-FEB-23      5873629
         3        117 INACTIVE         21-FEB-23      5853682
         2        119 CURRENT          21-FEB-23   2.8147E+14




SQL> 
SQL> recover database until cancel using backup controlfile;
ORA-00279: change 5907405 generated at 02/22/2023 01:05:42 needed for thread 1
ORA-00289: suggestion : u01/app/oracle/arch/1_119_1098480796.dbf
ORA-00280: change 5907405 for thread 1 is in sequence #119








Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/home/oracle/redo02.log
Log applied.
Media recovery complete.

--恢复正常完成。

6、恢复完成后再次尝试打开数据库

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

--提示需要以resetlogs方式打开数据库。

7、以resetlogs方式打开数据库

SQL> alter database open resetlogs;




Database altered.
SQL> select instance_name,status from v$instance;




INSTANCE_NAME    STATUS
---------------- ------------
mysource         OPEN




SQL> select group#,sequence#,status,first_time,next_change# from v$log;




    GROUP#  SEQUENCE# STATUS           FIRST_TIM NEXT_CHANGE#
---------- ---------- ---------------- --------- ------------
         1          1 CURRENT          13-MAY-23   2.8147E+14
         2          0 UNUSED                                0
         3          0 UNUSED                                0

--数据库进行了不完整恢复，以resetlogs方式打开了。

8、总结

遇到了两次这种情况，如果放在生产环境，那真是不应该出现掉电导致日志写出错的情况。所以：

1、生产环境的Oracle数据库，已开启归档模式的情况下，避免机器突然掉电，或者以shutdown abort方式关库，防止出现日志写不能正常完成而出现异常；

2、出现了报错，就算是ora-600或者ora-07445，先要进一步分析错误的类型或者方向，不要着急或者盲目操作；

3、对于生产环境，有先打开数据库，优先恢复业务，后面再进行详细的分析。

4、遇到ora-600也不可怕，悠着来，并不是所有的ora-600内部错误都很难解决。

往期内容：

数据库国家标准有望推动国产数据库快速发展
postgresql 15.2一主一备集群数据库安装与配置实践
MySQL 8.0.33一主两从同步复制+MHA配置过程
产品设计与架构设计不可缺少的FMEA
漫说数据库||使用服装流行特征来看数据库技术流行情况
国产数据技术的未来|国产数据库的江山何时平定

oracle 笔记本电脑数据库 oracle数据库 sql数据库

文章转载自skylines，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

我的Oracle数据库又打不开了，碰到了ORA-00600:[kcratr_nab_less_than_odr]

评论