ORA-00600 kcratr_nab_less_than_odr 处理小计51CTO博客 - 众发娱乐

ORA-00600 kcratr_nab_less_than_odr 处理小计51CTO博客

2019年03月06日09时35分22秒 | 作者: 辰龙 | 标签: 数据库,文件,康复 | 浏览: 1046

今日因为客户现场反常断电,oracle数据库又无法发动了。长途上去看看吧。

  1. 数据库只能mount,现已无法发动

    SQL> select status from v$instance;
    STATUS
    
    MOUNTED
    SQL> ALTER DATABASE OPEN;
    ALTER DATABASE OPEN
    *
    ERROR at line 1:
    ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
  2. 测验recover和resetlogs open都不可

    SQL> recover database;
    ORA-00283: recovery session canceled due to errors
    ORA-01610: recovery using the BACKUP CONTROLFILE option must be done
    SQL> ALTER DATABASE OPEN resetlogs;
    ALTER DATABASE OPEN resetlogs
    *
    ERROR at line 1:
    ORA-01113: file 1 needs media recovery
    ORA-01110: data file 1: D:\APP\ORACLE\ORADATA\PRJDB\SYSTEM01.DBF
  3. Alert log 显现过错

    ~~~~~~~~~~~~~~~~
    Sun Jan 14 19:52:29 2018
    ALTER DATABASE OPEN
    Beginning crash recovery of 1 threads
    parallel recovery started with 3 processes
    ......
    Started redo scan
    Completed redo scan
    read 2300 KB redo, 0 data blocks need recovery
    Errors in file d:\app\oracle\diag\rdbms\prjdb\prjdb\trace\prjdb_ora_1644.trc  (incident=315209):
    ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [29904], [4864], [4870], [], [], [], [], [], [], []
    Incident details in: d:\app\oracle\diag\rdbms\prjdb\prjdb\incident\incdir_315209\prjdb_ora_1644_i315209.trc
    Aborting crash recovery due to error 600
    Errors in file d:\app\oracle\diag\rdbms\prjdb\prjdb\trace\prjdb_ora_1644.trc:
    ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [29904], [4864], [4870], [], [], [], [], [], [], []
    Errors in file d:\app\oracle\diag\rdbms\prjdb\prjdb\trace\prjdb_ora_1644.trc:
    ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [29904], [4864], [4870], [], [], [], [], [], [], []
    ORA-600 signalled during: ALTER DATABASE OPEN...
    ~~~~~~~~~~~~~~~~~~~
  4. 结合ALERT里的过错ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [29904], [4864], [4870],是因为服务器反常断电,导致LGWR写redo log时失利,
    下次重新发动数据库时,需求做实例级康复,而又无法从联机日志文件里获取到这些redo信息,因为前次断电时,写日志失利了。

  5. 那么ORA-00600的过错里,那几个参数 [1], [29904], [4864], [4870]的意义是,实例需求康复sequence为29904的redo文件,需求康复到编号为4870的日志块,而实际上只能康复到第4864个日志块儿,所以数据库就不能正常发动。

  6. 那咱们怎么办呢?先查看一下操控文件和datafile记载的checkpoint_change#信息吧。

数据文件查看点(记载在操控文件中)

SQL> select file#,checkpoint_change#,last_change# from v$datafile where rownum<5;
 FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
  
 1  664629049
 2  664629049
 3  664629049
 4  664629049

体系查看点(记载在操控文件中)

SQL>  select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
  
 664607310

数据文件头查看点(记载在数据文件中)

SQL> select file#,checkpoint_change# from v$datafile_header where rownum<5;
 FILE# CHECKPOINT_CHANGE#
 
 1  664629049
 2  664629049
 3  664629049
 4  664629049

-7. 以上三个checkpoint_change#要共同(只读、脱机表空间在外),数据库才干正常翻开。否则会需求进行一步的处理。正常关库时,会生成新的查看点,写入上述三个checkpoint_change#,一起数据文件中的last_change#也会记载下该查看点,也就是说三个checkpoint_change#与last_change#记载着同一个值。

-8. 经过上面的过错,以及checkpoint_change#的不共同,现已能够承认,就是操控文件,因为断电。导致的controlfile损坏(checkpoint_change#不共同)。

-9. 因为没有备份,咱们只能经过重建controlfile的方法,来处理这个问题。

指定trace文件的生成途径
SQL&gt; alter database backup controlfile to trace as /tmp/controlfile.trc;

生成文件提取建库脚本如下,发动数据库到nomount状况,履行下面脚本。
留意:相似的康复操作,先将现有的数据库进行备份。即便这个数据库现已无法发动。咱们也要避免康复操作导致的更严峻的问题。

CREATE CONTROLFILE REUSE DATABASE "PRJDB" NORESETLOGS FORCE LOGGING ARCHIVELOG
  MAXLOGFILES 16
  MAXLOGMEMBERS 3
  MAXDATAFILES 200
  MAXINSTANCES 8
  MAXLOGHISTORY 584
LOGFILE
  GROUP 1 D:\APP\ORACLE\ORADATA\PRJDB\REDO01.LOG  SIZE 50M BLOCKSIZE 512,
  GROUP 2 D:\APP\ORACLE\ORADATA\PRJDB\REDO02.LOG  SIZE 50M BLOCKSIZE 512,
  GROUP 3 D:\APP\ORACLE\ORADATA\PRJDB\REDO03.LOG  SIZE 50M BLOCKSIZE 512
DATAFILE
  D:\APP\ORACLE\ORADATA\PRJDB\SYSTEM01.DBF,
  D:\APP\ORACLE\ORADATA\PRJDB\SYSAUX01.DBF,
  D:\APP\ORACLE\ORADATA\PRJDB\UNDOTBS01.DBF,
  D:\APP\ORACLE\ORADATA\PRJDB\USERS01.DBF
CHARACTER SET US7ASCII; 

-10. 查看数据库状况

SQL> select status from v$instance;
STATUS
  - -
MOUNTED

-11. 测验重启一下,看到是需求康复的(其实我是知道这样起不来的,可是就像固执的看看报错)。

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: D:\APP\ORACLE\ORADATA\PRJDB\SYSTEM01.DBF

-12. 康复数据库,其实啥也没做,recover就是走个过场,可是必须得走这个流程。

SQL> recover database;
Media recovery complete.
  1. 发动数据库,成功

    SQL> alter database open;
    Database altered.
    SQL> select status from v$instance;
    STATUS
    - 
    OPEN
  2. 再看看checkpoint_change#值,一致了吧。
    SQL> select file#,checkpoint_change#,last_change# from v$datafile where rownum<5;
     FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
      
     1  664649053
     2  664649053
     3  664649053
     4  664649053
    SQL> select checkpoint_change# from v$database;
    CHECKPOINT_CHANGE#
    
     664649053
    SQL> select file#,checkpoint_change# from v$datafile_header where rownum<5;
     FILE# CHECKPOINT_CHANGE#
     
     1  664649053
     2  664649053
     3  664649053
     4  664649053

最终,再啰嗦一下,备份真的很重要!很简略!
没有备份的数据库,不单单是裸奔那么简略!
不出问题,丢人!出问题,伤身啊!!

怎么重建操控文件,请参阅:

参阅链接:
http://wallimn.iteye.com/blog/1199561

版权声明
本文来源于网络,版权归原作者所有,其内容与观点不代表众发娱乐立场。转载文章仅为传播更有价值的信息,如采编人员采编有误或者版权原因,请与我们联系,我们核实后立即修改或删除。

猜您喜欢的文章