【ORA-600】12c R1上的600[kcratr_nab_less_than_odr]

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638 QQ号:47079569 邮箱:service@parnassusdata.com

SQL> startup;
ORACLE instance started.

Total System Global Area 1419685888 bytes
Fixed Size                  2288344 bytes
Variable Size             536872232 bytes
Database Buffers          872415232 bytes
Redo Buffers                8110080 bytes
Database mounted.
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [2],
[38], [4248], [4250], [], [], [], [], [], [], []


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], [2],
[38], [4248], [4250], [], [], [], [], [], [], []


SQL> 
SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name
/s01/diag/rdbms/mac/MAC_1/trace/MAC_1_ora_8585.trc



----------------------------------------------
WARNING! Crash recovery of thread 2 seq 38 is
ending at redo block 4248 but should not have ended before
redo block 4250
Incident 19490 created, dump file: /s01/diag/rdbms/mac/MAC_1/incident/incdir_19490/MAC_1_ora_8585_i19490.trc
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [2], [38], [4248], [4250], [], [], [], [], [], [], []

2013-07-07 01:01:41.295135 : Abort recovery for domain 0, flags = 0x4
2013-07-07 01:01:41.295177 : kjb_abort_recovery: domain flags=0x0, valid=0
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [2], [38], [4248], [4250], [], [], [], [], [], [], []
2013-07-07 01:01:41.295860 : Abort recovery for domain 0, flags = 0x4
2013-07-07 01:01:41.295876 : aborting recovery of 0 (0) with cluster inc 2 (0) recovery 1
2013-07-07 01:01:41.295890 : kjb_abort_recovery: domain flags=0x0, valid=0
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [2], [38], [4248], [4250], [], [], [], [], [], [], []

*** 2013-07-07 01:01:51.235
*** 2013-07-07 01:01:51.235800 13917 dbsdrv.c
Successfully allocated 2 recovery slaves
Parallel Media Recovery started with 2 slaves

*** 2013-07-07 01:02:07.397
Slave# 3: PR01 exited
Slave# 2: PR02 exited
Slave# 1: PR00 exited
ksvp2penabled: ep->flg = 0, rpr->slv_flg = 0
ksvp2penabled: ep = 0x7f9d0f67fe98, rpr = 0xb4da61c8

*** 2013-07-07 01:02:11.666
2013-07-07 01:02:11.666458 : Start recovery for domain=0, valid=0, flags=0x4
Successfully allocated 2 recovery slaves
Using 67 overflow buffers per recovery slave
Thread 2 checkpoint: logseq 38, block 2, scn 2678499
  cache-low rba: logseq 38, block 3797
    on-disk rba: logseq 38, block 4250, scn 2679872
  start recovery at logseq 38, block 3797, scn 0
Thread 1 checkpoint: logseq 35, block 2, scn 2661821
  cache-low rba: logseq 35, block 52000
    on-disk rba: logseq 35, block 52006, scn 2679836
  start recovery at logseq 35, block 52000, scn 0

*** 2013-07-07 01:02:11.696
Started writing zeroblks thread 1 seq 35 blocks 52006-52013
WARNING! Crash recovery of thread 2 seq 38 is
ending at redo block 4248 but should not have ended before
redo block 4250
Incident 19491 created, dump file: /s01/diag/rdbms/mac/MAC_1/incident/incdir_19491/MAC_1_ora_8585_i19491.trc
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [2], [38], [4248], [4250], [], [], [], [], [], [], []

2013-07-07 01:02:12.266277 : Abort recovery for domain 0, flags = 0x4
2013-07-07 01:02:12.266316 : kjb_abort_recovery: domain flags=0x0, valid=0
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [2], [38], [4248], [4250], [], [], [], [], [], [], []
2013-07-07 01:02:12.266546 : Abort recovery for domain 0, flags = 0x4
2013-07-07 01:02:12.266566 : aborting recovery of 0 (0) with cluster inc 2 (0) recovery 1
2013-07-07 01:02:12.266578 : kjb_abort_recovery: domain flags=0x0, valid=0
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [2], [38], [4248], [4250], [], [], [], [], [], [], []



SQL> oradebug setmypid
Statement processed.
SQL> oradebug dump controlf 3;
Statement processed.
SQL> oradebug tracefile_name
/s01/diag/rdbms/mac/MAC_1/trace/MAC_1_ora_8898.trc

low cache rba:(0x26.ed5.0) on disk rba:(0x26.109a.0)
on disk scn: 0x0000.0028e440 07/06/2013 13:11:33

原因是读取thread 2的redo logfile发现其仅写到4248个块, 但实际control中记录ON DISK DBA该为109a 即4250。

尝试重建控制文件:

SQL> alter database backup controlfile to trace;

Database altered.



SQL> alter system set cluster_database=false scope=spfile;

System altered.

SQL> startup force nomount;
ORACLE instance started.

Total System Global Area 1419685888 bytes
Fixed Size                  2288344 bytes
Variable Size             536872232 bytes
Database Buffers          872415232 bytes
Redo Buffers                8110080 bytes

CREATE CONTROLFILE REUSE DATABASE "MAC" NORESETLOGS  NOARCHIVELOG
    MAXLOGFILES 192
    MAXLOGMEMBERS 3
    MAXDATAFILES 1024
    MAXINSTANCES 32
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 (
    '+DATADG/MAC/ONLINELOG/group_1.263.819691857',
    '+DATADG/MAC/ONLINELOG/group_1.264.819691859'
  ) SIZE 50M BLOCKSIZE 512,
  GROUP 2 (
    '+DATADG/MAC/ONLINELOG/group_2.265.819691861',
    '+DATADG/MAC/ONLINELOG/group_2.266.819691861'
  ) SIZE 50M BLOCKSIZE 512,
  GROUP 3 (
     '+DATADG/MAC/ONLINELOG/group_3.272.819692415',
    '+DATADG/MAC/ONLINELOG/group_3.273.819692417'
  ) SIZE 50M BLOCKSIZE 512,
  GROUP 4 (
    '+DATADG/MAC/ONLINELOG/group_4.274.819692419',
    '+DATADG/MAC/ONLINELOG/group_4.275.819692421'
  ) SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
  '+DATADG/MAC/DATAFILE/system.258.819691771',
  '+DATADG/MAC/DATAFILE/sysaux.257.819691725',
  '+DATADG/MAC/DATAFILE/undotbs1.260.819691817',
  '+DATADG/MAC/DD7C48AA5A4404A2E04325AAE80A403C/DATAFILE/system.269.819691869',
   '+DATADG/MAC/DATAFILE/users.259.819691817',
  '+DATADG/MAC/DD7C48AA5A4404A2E04325AAE80A403C/DATAFILE/sysaux.268.819691869',
  '+DATADG/MAC/DATAFILE/undotbs2.271.819692307',
  '+DATADG/MAC/DD7D8C1D4C234B38E04325AAE80AF577/DATAFILE/system.279.819692587',
  '+DATADG/MAC/DD7D8C1D4C234B38E04325AAE80AF577/DATAFILE/sysaux.277.819692585',
  '+DATADG/MAC/DD7D8C1D4C234B38E04325AAE80AF577/DATAFILE/users.280.819692587',
  '+DATADG/MAC/DD7D8C1D4C234B38E04325AAE80AF577/DATAFILE/example.278.819692585'
CHARACTER SET AL32UTF8
;


RECOVER DATABASE
-- Database can now be opened normally.

alter system set cluster_database=true scope=spfile;

startup force mount;


ALTER DATABASE OPEN;
-- Open all the PDBs.
ALTER PLUGGABLE DATABASE ALL OPEN;
-- Commands to add tempfiles to temporary tablespaces.
-- Online tempfiles have complete space information.
-- Other tempfiles may require adjustment.
ALTER TABLESPACE TEMP ADD TEMPFILE '+DATADG/MAC/TEMPFILE/temp.267.819691865' REUSE;
ALTER SESSION SET CONTAINER = PDB$SEED;
ALTER TABLESPACE TEMP ADD TEMPFILE '+DATADG/MAC/DD7C48AA5A4404A2E04325AAE80A403C/DATAFILE/pdbseed_temp01.dbf' REUSE;

ALTER SESSION SET CONTAINER = MACC;
ALTER TABLESPACE TEMP ADD TEMPFILE '+DATADG/MAC/DD7D8C1D4C234B38E04325AAE80AF577/DATAFILE/macc_temp01.dbf' REUSE;
ALTER SESSION SET CONTAINER = CDB$ROOT;



重建控制文件后问题消失, 主要问题还是 主机断电对redo logfile的写丢失, 而控制文件却更新了on disk rba,导致控制文件中的RBA大于redo logfile中实际存在的, 通过重建控制文件后2者一致 从而问题消失。

关注dbDao.com的新浪微博

扫码关注dbDao.com 微信公众号:

Comments

  1. hctech says:

    请问这个是由bug引起的么?不然为何会出现redo没写完就更新控制文件呢?

  2. 如文中最后段落所述“主要问题还是 主机断电对redo logfile的写丢失”

  3. hctech says:

    那既然主机断电会出现这种情况,为何oracle不在写完redo file之后才更新on disk rba?请教一下这个过程到底是如何保证一致性的,谢谢刘大!

  4. Oracle认为2者都写出了, 但OS并不保证这一点

Speak Your Mind

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569