ORA-600 kcratr_nab_less_than_odr和ORA-600 4194故障处理

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:ORA-600 kcratr_nab_less_than_odr和ORA-600 4194故障处理

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

客户一个11.2.0.1的库由于断电导致启动的时候报ORA-600 kcratr_nab_less_than_odr错误
ORA-600-kcratr_nab_less_than_odr


Wed Aug 06 15:55:07 2025
ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
 parallel recovery started with 27 processes
Started redo scan
Completed redo scan
 read 11787 KB redo, 4129 data blocks need recovery
Errors in file d:\app\xff\diag\rdbms\primary\orcl\trace\orcl_ora_3520.trc  (incident=2624321):
ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [111988], [42537], [43285], [], [], [], [], [], [], []
Incident details in: d:\app\xff\diag\rdbms\primary\orcl\incident\incdir_2624321\orcl_ora_3520_i2624321.trc
Aborting crash recovery due to error 600
Errors in file d:\app\xff\diag\rdbms\primary\orcl\trace\orcl_ora_3520.trc:
ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [111988], [42537], [43285], [], [], [], [], [], [], []
Errors in file d:\app\xff\diag\rdbms\primary\orcl\trace\orcl_ora_3520.trc:
ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [111988], [42537], [43285], [], [], [], [], [], [], []
ORA-600 signalled during: ALTER DATABASE OPEN...

类似的ORA-600 kcratr_nab_less_than_odr故障处理不少,但是应用redo完成之后,再open报错的不多:
12c启动报kcratr_nab_less_than_odr
又一例ORA-600 kcratr_nab_less_than_odr
ORA-600 kcratr_nab_less_than_odr故障解决
差点被误操作的ORA-600 kcratr_nab_less_than_odr故障
11.2.0.4库中遇到ORA-600 kcratr_nab_less_than_odr报错
但是这个客户比较不幸,经过一系列尝试打开数据库,但是报ORA-600 4194错误

Wed Aug 06 17:09:33 2025
ALTER DATABASE RECOVER  database until cancel using backup controlfile  
Media Recovery Start
 started logmerger process
Parallel Media Recovery started with 28 slaves
ORA-279 signalled during: ALTER DATABASE RECOVER  database until cancel using backup controlfile  ...
Wed Aug 06 17:10:17 2025
ALTER DATABASE RECOVER    LOGFILE 'D:\app\xff\oradata\orcl\REDO05.LOG'  
Media Recovery Log D:\app\xff\oradata\orcl\REDO05.LOG
Wed Aug 06 17:10:17 2025
Incomplete recovery applied all redo ever generated.
Recovery completed through change 2118813100 time 08/06/2025 15:02:15
Completed: ALTER DATABASE RECOVER    LOGFILE 'D:\app\xff\oradata\orcl\REDO05.LOG'  
Wed Aug 06 17:14:05 2025
alter database open resetlogs
Archived Log entry 188143 added for thread 1 sequence 111985 ID 0x634438e6 dest 1:
Archived Log entry 188144 added for thread 1 sequence 111986 ID 0x634438e6 dest 1:
Archived Log entry 188145 added for thread 1 sequence 111987 ID 0x634438e6 dest 1:
Archived Log entry 188146 added for thread 1 sequence 111984 ID 0x634438e6 dest 1:
Archived Log entry 188147 added for thread 1 sequence 111988 ID 0x634438e6 dest 1:
RESETLOGS after complete recovery through change 2118813100
Resetting resetlogs activation ID 1665415398 (0x634438e6)
Wed Aug 06 17:15:03 2025
Archived Log entry 188148 added for thread 1 sequence 1 ID 0x677cfac1 dest 1:
Successfully onlined Undo Tablespace 2.
Dictionary check beginning
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is ZHS16GBK
No Resource Manager plan active
Errors in file d:\app\xff\diag\rdbms\primary\orcl\trace\orcl_smon_2428.trc  (incident=3264274):
ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [], [], [], [], []
Incident details in: d:\app\xff\diag\rdbms\primary\orcl\incident\incdir_3264274\orcl_smon_2428_i3264274.trc
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Wed Aug 06 17:15:06 2025
QMNC started with pid=34, OS id=3052 
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Completed: alter database open resetlogs

后续由于该undo异常报ORA-01595和ORA-600 4194等错误导致数据库crash

Wed Aug 06 17:15:49 2025
Doing block recovery for file 3 block 888
Resuming block recovery (PMON) for file 3 block 888
Block recovery from logseq 2, block 316 to scn 2118813732
Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0
  Mem# 0: D:\APP\xff\ORADATA\ORCL\REDO02.LOG
Block recovery stopped at EOT rba 2.447.16
Block recovery completed at rba 2.447.16, scn 0.2118813732
Doing block recovery for file 3 block 1960
Resuming block recovery (PMON) for file 3 block 1960
Block recovery from logseq 2, block 316 to scn 2118813622
Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0
  Mem# 0: D:\APP\xff\ORADATA\ORCL\REDO02.LOG
Block recovery completed at rba 2.317.16, scn 0.2118813626
Errors in file d:\app\xff\diag\rdbms\primary\orcl\trace\orcl_smon_2428.trc:
ORA-01595: error freeing extent (2) of rollback segment (27))
ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [], [], [], [], []

接手这个库之后,处理工作相对比较简单,直接对异常undo进行重建即可

Thu Aug 07 09:35:08 2025
create undo tablespace undotbs2 datafile 'D:\APP\xff\ORADATA\ORCL\undotbs02.dbf' size 128M autoextend on
Completed: create undo tablespace undotbs2 datafile 'D:\APP\xff\ORADATA\ORCL\undotbs02.dbf' size 128M autoextend on
Thu Aug 07 09:37:53 2025
drop tablespace UNDOTBS1 including contents and datafiles
Deleted file D:\APP\xff\ORADATA\ORCL\UNDOTBS01.DBF
Completed: drop tablespace UNDOTBS1 including contents and datafiles

然后数据库报大量的ORA-600 kdsgrp1错误

Thu Aug 07 10:03:53 2025
Errors in file d:\app\xff\diag\rdbms\primary\orcl\trace\orcl_ora_6156.trc  (incident=5121829):
ORA-00600: 内部错误代码, 参数: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
Thu Aug 07 10:04:00 2025
Errors in file d:\app\xff\diag\rdbms\primary\orcl\trace\orcl_ora_4564.trc  (incident=5121501):
ORA-00600: 内部错误代码, 参数: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
Thu Aug 07 10:04:06 2025
Errors in file d:\app\xff\diag\rdbms\primary\orcl\trace\orcl_ora_9160.trc  (incident=5121837):
ORA-00600: 内部错误代码, 参数: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
Thu Aug 07 10:04:16 2025
Errors in file d:\app\xff\diag\rdbms\primary\orcl\trace\orcl_ora_5868.trc  (incident=5121821):
ORA-00600: 内部错误代码, 参数: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
Thu Aug 07 10:04:28 2025
Errors in file d:\app\xff\diag\rdbms\primary\orcl\trace\orcl_ora_4448.trc  (incident=5122077):
ORA-00600: 内部错误代码, 参数: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
* kdsgrp1-1: *************************************************
            row 0x013a9ae9.0 continuation at
            0x013a9ae9.0 file# 4 block# 3840745 slot 0 not found
KDSTABN_GET: 0 ..... ntab: 1
curSlot: 0 ..... nrows: 2
kdsgrp - dump CR block dba=0x013a9ae9
Block header dump:  0x013a9ae9
 Object id on Block? Y
 seg/obj: 0x31dd9  csc: 0x00.7dc0f246  itc: 2  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x13a9082 ver: 0x01 opc: 0
     inc: 2  exflg: 0
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000

通过分析是由于index和表记录不匹配导致,对index进行重新rebuild完成本次修复任务.

差点被误操作的ORA-600 kcratr_nab_less_than_odr故障

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:差点被误操作的ORA-600 kcratr_nab_less_than_odr故障

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

晚上接到一个客户电话,数据库无法启动,咨询我的Oracle Recovery Tools工具的授权问题,我远程登录客户的环境进行查看故障,发现客户进行了一下操作导致最后open报ORA-01152错误

C:\Users\Administrator>sqlplus sys/sys as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Tue Mar 18 22:43:24 2025

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


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

SQL> startup mount
ORACLE instance started.

Total System Global Area 1603411968 bytes
Fixed Size                  2176168 bytes
Variable Size             973081432 bytes
Database Buffers          620756992 bytes
Redo Buffers                7397376 bytes
Database mounted.
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],
[27890], [1589], [1649], [], [], [], [], [], [], []

SQL> recover database;
ORA-00283: 恢复会话因错误而取消
ORA-00264: 不要求恢复


SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1],
[27890], [1589], [1649], [], [], [], [], [], [], []


SQL> recover database until cancel;
ORA-10879: error signaled in parallel recovery slave
ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01152: 文件 1 没有从过旧的备份中还原
ORA-01110: 数据文件 1: 'D:\APP\ADMINISTRATOR\ORADATA\orcl\SYSTEM01.DBF'

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: 'D:\APP\ADMINISTRATOR\ORADATA\orcl\SYSTEM01.DBF'


SQL> RECOVER DATABASE USING BACKUP CONTROLFILE;
ORA-00279: change 17384974762395 generated at 03/18/2025 18:30:34 needed for
thread 1
ORA-00289: suggestion :
D:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\orcl\ARCHIVELOG\2025_03_19\O1_MF_1_27
890_%U_.ARC
ORA-00280: change 17384974762395 for thread 1 is in sequence #27890


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
D\APP\ADMINISTRATOR\ORADATA\orcl\RED001.LOG
ORA-00308: 无法打开归档日志 'D\APP\ADMINISTRATOR\ORADATA\orcl\RED001.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 3) 系统找不到指定的路径。


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
D:\app\Administrator\oradata\orcl\RED001.LOG
ORA-00308: 无法打开归档日志 'D:\app\Administrator\oradata\orcl\RED001.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。

最初数据库启动报ORA-600 kcratr_nab_less_than_odr错误(这个是一个非常典型的错误,早期写过处理方法:ORA-600 kcratr_nab_less_than_odr故障解决),客户处理故障思路不太清晰,使用了recover database until cancel和alter database open resetlogs等不当操作,导致数据库没有open成功.然后希望使用我的Oracle Recovery Tools小工具进行修复,但是根据我的判断,这个故障还用不上该工具,直接可以open库.对其进行ctl重建并open库

SQL> alter database backup controlfile to trace as 'd:/ctl.txt';

Database altered.

SQL> create pfile='d:/pfile.txt' from spfile;

File created.

SQL> shutdown immediate;
ORA-01109: database not open


Database dismounted.
ORACLE instance shut down.
SQL> startup nomount;
ORACLE instance started.

Total System Global Area 1603411968 bytes
Fixed Size                  2176168 bytes
Variable Size             973081432 bytes
Database Buffers          620756992 bytes
Redo Buffers                7397376 bytes
SQL> @d:/xifenfei/rectl.sql

Control file created.

SQL>
SQL>
SQL> recover database;
Media recovery complete.

SQL> alter database open;

Database altered.

在open之后,数据库报ORA-600 4194错误

Wed Mar 19 01:51:12 2025
alter database open
Beginning crash recovery of 1 threads
 parallel recovery started with 23 processes
Started redo scan
Completed redo scan
 read 793 KB redo, 0 data blocks need recovery
Started redo application at
 Thread 1: logseq 27890, block 2, scn 17384974741793
Recovery of Online Redo Log: Thread 1 Group 4 Seq 27890 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\orcl\REDO04.LOG
Completed redo application of 0.00MB
Completed crash recovery at
 Thread 1: logseq 27890, block 1589, scn 17384974762395
 0 data blocks read, 0 data blocks written, 793 redo k-bytes read
Wed Mar 19 01:51:14 2025
Thread 1 advanced to log sequence 27891 (thread open)
Thread 1 opened at log sequence 27891
  Current log# 2 seq# 27891 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\orcl\REDO02.LOG
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Wed Mar 19 01:51:14 2025
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Dictionary check beginning
Tablespace 'TEMP' #3 found in data dictionary,
but not in the controlfile. Adding to controlfile.
Tablespace 'TEMP1' #11 found in data dictionary,
but not in the controlfile. Adding to controlfile.
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
*********************************************************************
WARNING: The following temporary tablespaces contain no files.
         This condition can occur when a backup controlfile has
         been restored.  It may be necessary to add files to these
         tablespaces.  That can be done using the SQL statement:
 
         ALTER TABLESPACE <tablespace_name> ADD TEMPFILE
 
         Alternatively, if these temporary tablespaces are no longer
         needed, then they can be dropped.
           Empty temporary tablespace: TEMP
           Empty temporary tablespace: TEMP1
*********************************************************************
Database Characterset is ZHS16GBK
No Resource Manager plan active
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_4084.trc  (incident=158542):
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_158542\orcl_smon_4084_i158542.trc
Wed Mar 19 01:51:26 2025
Trace dumping is performing id=[cdmp_20250319015126]
Wed Mar 19 01:51:31 2025
Sweep [inc][158542]: completed
Sweep [inc2][158542]: completed
Wed Mar 19 01:51:35 2025
Doing block recovery for file 3 block 1415
Resuming block recovery (PMON) for file 3 block 1415
Block recovery from logseq 27891, block 86 to scn 17384974782720
Recovery of Online Redo Log: Thread 1 Group 2 Seq 27891 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\orcl\REDO02.LOG
Block recovery stopped at EOT rba 27891.87.16
Block recovery completed at rba 27891.87.16, scn 4047.3242135803
Doing block recovery for file 3 block 264
Resuming block recovery (PMON) for file 3 block 264
Block recovery from logseq 27891, block 86 to scn 17384974782714
Recovery of Online Redo Log: Thread 1 Group 2 Seq 27891 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\orcl\REDO02.LOG
Block recovery completed at rba 27891.87.16, scn 4047.3242135803
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_4084.trc:
ORA-01595: 释放区 (2) 回退段 (12) 时出错
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
Wed Mar 19 01:51:36 2025
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_5680.trc  (incident=158590):
ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_158590\orcl_ora_5680_i158590.trc

数据库open成功,但是后台报ORA-01595/ORA-600 4194错误,这个问题比较常见,直接处理异常undo即可恢复.

ORA-01595/ORA-600 4194处理

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:ORA-01595/ORA-600 4194处理

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

又一个客户由于服务器断电,导致oracle无法正常启动报ORA-600 4194错误

Sat Jan 20 13:45:22 2024
ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
 parallel recovery started with 32 processes
Started redo scan
Completed redo scan
 read 31 KB redo, 5 data blocks need recovery
Started redo application at
 Thread 1: logseq 9, block 3
Recovery of Online Redo Log: Thread 1 Group 3 Seq 9 Reading mem 0
  Mem# 0: D:\ORACLE\ORADATA\xff\REDO03.LOG
Completed redo application of 0.02MB
Completed crash recovery at
 Thread 1: logseq 9, block 66, scn 81924188
 5 data blocks read, 5 data blocks written, 31 redo k-bytes read
Thread 1 advanced to log sequence 10 (thread open)
Thread 1 opened at log sequence 10
  Current log# 1 seq# 10 mem# 0: D:\ORACLE\ORADATA\xff\REDO01.LOG
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is AL32UTF8
No Resource Manager plan active
Errors in file d:\oracle\diag\rdbms\xff\xff\trace\xff_smon_5164.trc  (incident=384222):
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
Incident details in: d:\oracle\diag\rdbms\xff\xff\incident\incdir_384222\xff_smon_5164_i384222.trc
Errors in file d:\oracle\diag\rdbms\xff\xff\trace\xff_ora_6832.trc  (incident=384270):
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
Incident details in: d:\oracle\diag\rdbms\xff\xff\incident\incdir_384270\xff_ora_6832_i384270.trc
Doing block recovery for file 3 block 207
Resuming block recovery (PMON) for file 3 block 207
Block recovery from logseq 10, block 64 to scn 81924393
Recovery of Online Redo Log: Thread 1 Group 1 Seq 10 Reading mem 0
  Mem# 0: D:\ORACLE\ORADATA\xff\REDO01.LOG
Block recovery stopped at EOT rba 10.66.16
Block recovery completed at rba 10.66.16, scn 0.81924391
Doing block recovery for file 3 block 160
Resuming block recovery (PMON) for file 3 block 160
Block recovery from logseq 10, block 64 to scn 81924389
Recovery of Online Redo Log: Thread 1 Group 1 Seq 10 Reading mem 0
  Mem# 0: D:\ORACLE\ORADATA\xff\REDO01.LOG
Block recovery completed at rba 10.64.16, scn 0.81924390
Errors in file d:\oracle\diag\rdbms\xff\xff\trace\xff_smon_5164.trc:
ORA-01595: 释放区 (2) 回退段 (3) 时出错
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
Trace dumping is performing id=[cdmp_20240120134525]
Doing block recovery for file 3 block 3857
Resuming block recovery (PMON) for file 3 block 3857
Block recovery from logseq 10, block 64 to scn 81924396
Recovery of Online Redo Log: Thread 1 Group 1 Seq 10 Reading mem 0
  Mem# 0: D:\ORACLE\ORADATA\xff\REDO01.LOG
Block recovery stopped at EOT rba 10.66.16
Block recovery completed at rba 10.66.16, scn 0.81924391
Doing block recovery for file 3 block 272
Resuming block recovery (PMON) for file 3 block 272
Block recovery from logseq 10, block 64 to scn 81924390
Recovery of Online Redo Log: Thread 1 Group 1 Seq 10 Reading mem 0
  Mem# 0: D:\ORACLE\ORADATA\xff\REDO01.LOG
Block recovery completed at rba 10.66.16, scn 0.81924391
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Sat Jan 20 13:45:26 2024
QMNC started with pid=56, OS id=8052 
Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0x66F8B134] [PC:0x93C7D88, kgegpa()+38]
Dump file d:\oracle\diag\rdbms\xff\xff\trace\alert_xff.log
Doing block recovery for file 3 block 3857
Resuming block recovery (PMON) for file 3 block 3857
Block recovery from logseq 10, block 64 to scn 81924396
Recovery of Online Redo Log: Thread 1 Group 1 Seq 10 Reading mem 0
  Mem# 0: D:\ORACLE\ORADATA\xff\REDO01.LOG
Block recovery completed at rba 10.66.16, scn 0.81924399
Errors in file d:\oracle\diag\rdbms\xff\xff\trace\xff_mmon_7876.trc  (incident=396089):
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-06512: 在 "SYS.DBMS_HA_ALERTS_PRVT", line 310
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], 
Doing block recovery for file 3 block 3857
Resuming block recovery (PMON) for file 3 block 3857
Block recovery from logseq 10, block 64 to scn 81924396
Recovery of Online Redo Log: Thread 1 Group 1 Seq 10 Reading mem 0
  Mem# 0: D:\ORACLE\ORADATA\xff\REDO01.LOG
Block recovery completed at rba 10.66.16, scn 0.81924399
Errors in file d:\oracle\diag\rdbms\xff\xff\trace\xff_pmon_8876.trc  (incident=384102):
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
Sat Jan 20 13:45:39 2024
Errors in file d:\oracle\diag\rdbms\xff\xff\trace\xff_pmon_8876.trc:
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
PMON (ospid: 8876): terminating the instance due to error 472
Instance terminated by PMON, pid = 8876

这个故障比较简单,由于undo回滚异常导致,对异常的undo进行处理,数据库正常open,重建undo表空间导出数据,完成本次恢复工作

又一例ORA-600 kcratr_nab_less_than_odr

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:又一例ORA-600 kcratr_nab_less_than_odr

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

数据库启动报错ORA-600 kcratr_nab_less_than_odr

alter database open
Sat Jul 23 21:38:32 2022
Beginning crash recovery of 1 threads
 parallel recovery started with 19 processes
Sat Jul 23 21:38:33 2022
Started redo scan
Sat Jul 23 21:38:33 2022
Completed redo scan
 read 244 KB redo, 64 data blocks need recovery
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl12c\orcl12c\trace\orcl12c_ora_5748.trc  (incident=309845):
ORA-00600: ??????, ??: [kcratr_nab_less_than_odr], [1], [10343], [67442], [67454], [], [], [], [], [], [], []
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:34 2022
Slave encountered ORA-10388 exception during crash recovery
Sat Jul 23 21:38:38 2022
Aborting crash recovery due to error 600
Sat Jul 23 21:38:38 2022
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl12c\orcl12c\trace\orcl12c_ora_5748.trc:
ORA-00600: ??????, ??: [kcratr_nab_less_than_odr], [1], [10343], [67442], [67454], [], [], [], [], [], [], []
Sat Jul 23 21:38:39 2022
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl12c\orcl12c\trace\orcl12c_ora_5748.trc:
ORA-00600: ??????, ??: [kcratr_nab_less_than_odr], [1], [10343], [67442], [67454], [], [], [], [], [], [], []
ORA-600 signalled during: alter database open...

这个错误比较简单,参考:
12c启动报kcratr_nab_less_than_odr
ORA-600 kcratr_nab_less_than_odr故障解决
解决该问题之后,数据库启动报ORA-600 4194错误

Mon Jul 25 12:18:04 2022
SMON: enabling tx recovery
Starting background process SMCO
Mon Jul 25 12:18:05 2022
SMCO started with pid=26, OS id=8164 
Mon Jul 25 12:18:06 2022
Database Characterset is ZHS16GBK
ORA-00600: ??????, ??: [4194], [46], [44], [], [], [], [], [], [], [], [], []
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Mon Jul 25 12:18:14 2022
Doing block recovery for file 5 block 1267
Mon Jul 25 12:18:14 2022
Resuming block recovery (PMON) for file 5 block 1267
Block recovery from logseq 1, block 67 to scn 217083444
Mon Jul 25 12:18:15 2022
Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL12C\REDO01.LOG
Block recovery stopped at EOT rba 1.68.16
Block recovery completed at rba 1.68.16, scn 0.217083444
Doing block recovery for file 5 block 272
Resuming block recovery (PMON) for file 5 block 272
Block recovery from logseq 1, block 67 to scn 217083443
Mon Jul 25 12:18:18 2022
Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL12C\REDO01.LOG
Block recovery completed at rba 1.68.16, scn 0.217083444
Mon Jul 25 12:18:19 2022
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl12c\orcl12c\trace\orcl12c_smon_7100.trc:
ORA-01595: 释放区 (5) 回退段 (10) 时出错
ORA-00600: ??????, ??: [4194], [46], [44], [], [], [], [], [], [], [], [], []
Mon Jul 25 12:18:19 2022
No Resource Manager plan active
Mon Jul 25 12:18:23 2022
Sweep [inc][317000]: completed
Sweep [inc2][317000]: completed
Starting background process FBDA
Mon Jul 25 12:18:40 2022
FBDA started with pid=28, OS id=7828 
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl12c\orcl12c\trace\orcl12c_ora_5804.trc  (incident=317056):
ORA-00600: 内部错误代码, 参数: [4194], [46], [44], [], [], [], [], [], [], [], [], []
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Mon Jul 25 12:18:53 2022
Doing block recovery for file 5 block 1267
Resuming block recovery (PMON) for file 5 block 1267
Block recovery from logseq 1, block 67 to scn 217083444
Mon Jul 25 12:18:53 2022
Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL12C\REDO01.LOG
Block recovery completed at rba 1.68.16, scn 0.217083454
Doing block recovery for file 5 block 272
Resuming block recovery (PMON) for file 5 block 272
Block recovery from logseq 1, block 67 to scn 217083454
Mon Jul 25 12:18:54 2022
Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL12C\REDO01.LOG
Block recovery completed at rba 1.69.16, scn 0.217083455
Mon Jul 25 12:18:55 2022
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl12c\orcl12c\trace\orcl12c_ora_5804.trc:
ORA-00600: 内部错误代码, 参数: [4194], [46], [44], [], [], [], [], [], [], [], [], []
Mon Jul 25 12:18:55 2022
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl12c\orcl12c\trace\orcl12c_ora_5804.trc:
ORA-00600: 内部错误代码, 参数: [4194], [46], [44], [], [], [], [], [], [], [], [], []
Error 600 happened during db open, shutting down database
USER (ospid: 5804): terminating the instance due to error 600
Mon Jul 25 12:19:07 2022
Instance terminated by USER, pid = 5804
ORA-1092 signalled during: alter database open resetlogs...

该错误也比较简单,对异常undo段进行处理即可,参考类似操作:How to resolve ORA-600 [4194] errors

ORA-00333 ORA-01595 恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:ORA-00333 ORA-01595 恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

客户反馈数据库异常,查看日志发现asm和db均发生hang住情况(由于环境原因部分日志没有拷贝出来),基于现有情况,无法直接恢复,通过一些工具把asm磁盘组中的数据文件拷贝到文件系统,经过检测无坏块
20220705233329


修改相关路径,尝试recover库

Tue Jul 05 15:05:54 2022
ALTER DATABASE RECOVER  datafile 1  
Media Recovery Start
Serial Media Recovery started
Recovery of Online Redo Log: Thread 2 Group 4 Seq 29973 Reading mem 0
  Mem# 0: E:\ORADATA\GROUP_4.266.822672441
Recovery of Online Redo Log: Thread 1 Group 2 Seq 38422 Reading mem 0
  Mem# 0: E:\ORADATA\GROUP_2.262.822672137
Incomplete read from log member 'E:\ORADATA\GROUP_2.262.822672137'. Trying next member.
Media Recovery failed with error 333
ORA-283 signalled during: ALTER DATABASE RECOVER  datafile 1  ...

ORA-00333


错误信息比较明显,在读入redo进行恢复的时候遭遇“ORA-00333: 重做日志读取块 11557 计数 731 出错”错误,从而无法继续恢复.这次故障运气比较好,通过分析v$datafile和v$datafile_header关系
20220705233008

进行一些操作,绕过redo block 11557,顺利recover成功,并且open库

ALTER DATABASE RECOVER  database  
Media Recovery Start
 started logmerger process
Tue Jul 05 15:17:46 2022
Parallel Media Recovery started with 32 slaves
Tue Jul 05 15:17:46 2022
Recovery of Online Redo Log: Thread 2 Group 4 Seq 29973 Reading mem 0
  Mem# 0: E:\ORADATA\GROUP_4.266.822672441
Recovery of Online Redo Log: Thread 1 Group 2 Seq 38422 Reading mem 0
  Mem# 0: E:\ORADATA\GROUP_2.262.822672137
Completed: ALTER DATABASE RECOVER  database  

20220705232246


通过分析alert日志发现有ORA-600 4194错误

QMNC started with pid=58, OS id=15980 
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Tue Jul 05 15:18:24 2022
Tue Jul 05 15:18:24 2022
Block recovery from logseq 38423, block 152 to scn 16218380250500
Recovery of Online Redo Log: Thread 1 Group 1 Seq 38423 Reading mem 0
  Mem# 0: E:\ORADATA\GROUP_1.261.822672135
Block recovery stopped at EOT rba 38423.154.16
Block recovery completed at rba 38423.154.16, scn 3776.583740804
Block recovery from logseq 38423, block 152 to scn 16218380250497
Recovery of Online Redo Log: Thread 1 Group 1 Seq 38423 Reading mem 0
  Mem# 0: E:\ORADATA\GROUP_1.261.822672135
Block recovery completed at rba 38423.154.16, scn 3776.583740804
Errors in file F:\APP\ADMINISTRATOR\diag\rdbms\xff\xff1\trace\xff1_smon_5660.trc:
ORA-01595: 释放区 (2) 回退段 (8) 时出错
ORA-00600: 内部错误代码, 参数: [4194], [], [
                                      
Completed: alter database open 

这比较简单,对于异常的undo进行处理即可,然后使用hcheck检查字典一致性

SQL> @e:/oradata/txt/11.txt
HCheck Version 07MAY18 on 05-7月 -2022 16:30:18
----------------------------------------------
Catalog Version 11.2.0.3.0 (1102000300)
db_name: xff

                                   Catalog       Fixed
Procedure Name                     Version    Vs Release    Timestamp
Result
------------------------------ ... ---------- -- ---------- --------------
------
.- LobNotInObj                 ... 1102000300 <=  *All Rel* 07/05 16:30:18 PASS
.- MissingOIDOnObjCol          ... 1102000300 <=  *All Rel* 07/05 16:30:19 PASS
.- SourceNotInObj              ... 1102000300 <=  *All Rel* 07/05 16:30:19 PASS
.- OversizedFiles              ... 1102000300 <=  *All Rel* 07/05 16:30:19 PASS
.- PoorDefaultStorage          ... 1102000300 <=  *All Rel* 07/05 16:30:19 PASS
.- PoorStorage                 ... 1102000300 <=  *All Rel* 07/05 16:30:19 PASS
.- TabPartCountMismatch        ... 1102000300 <=  *All Rel* 07/05 16:30:20 PASS
.- OrphanedTabComPart          ... 1102000300 <=  *All Rel* 07/05 16:30:20 PASS
.- MissingSum$                 ... 1102000300 <=  *All Rel* 07/05 16:30:20 PASS
.- MissingDir$                 ... 1102000300 <=  *All Rel* 07/05 16:30:20 PASS
.- DuplicateDataobj            ... 1102000300 <=  *All Rel* 07/05 16:30:20 PASS
.- ObjSynMissing               ... 1102000300 <=  *All Rel* 07/05 16:30:20 PASS
.- ObjSeqMissing               ... 1102000300 <=  *All Rel* 07/05 16:30:21 PASS
.- OrphanedUndo                ... 1102000300 <=  *All Rel* 07/05 16:30:21 PASS
.- OrphanedIndex               ... 1102000300 <=  *All Rel* 07/05 16:30:21 PASS
.- OrphanedIndexPartition      ... 1102000300 <=  *All Rel* 07/05 16:30:21 PASS
.- OrphanedIndexSubPartition   ... 1102000300 <=  *All Rel* 07/05 16:30:21 PASS
.- OrphanedTable               ... 1102000300 <=  *All Rel* 07/05 16:30:21 PASS
.- OrphanedTablePartition      ... 1102000300 <=  *All Rel* 07/05 16:30:21 PASS
.- OrphanedTableSubPartition   ... 1102000300 <=  *All Rel* 07/05 16:30:21 PASS
.- MissingPartCol              ... 1102000300 <=  *All Rel* 07/05 16:30:21 PASS
.- OrphanedSeg$                ... 1102000300 <=  *All Rel* 07/05 16:30:21 PASS
.- OrphanedIndPartObj#         ... 1102000300 <=  *All Rel* 07/05 16:30:21 PASS
.- DuplicateBlockUse           ... 1102000300 <=  *All Rel* 07/05 16:30:21 PASS
.- FetUet                      ... 1102000300 <=  *All Rel* 07/05 16:30:21 PASS
.- Uet0Check                   ... 1102000300 <=  *All Rel* 07/05 16:30:21 PASS
.- SeglessUET                  ... 1102000300 <=  *All Rel* 07/05 16:30:21 PASS
.- BadInd$                     ... 1102000300 <=  *All Rel* 07/05 16:30:21 PASS
.- BadTab$                     ... 1102000300 <=  *All Rel* 07/05 16:30:22 PASS
.- BadIcolDepCnt               ... 1102000300 <=  *All Rel* 07/05 16:30:22 PASS
.- ObjIndDobj                  ... 1102000300 <=  *All Rel* 07/05 16:30:22 PASS
.- TrgAfterUpgrade             ... 1102000300 <=  *All Rel* 07/05 16:30:22 PASS
.- ObjType0                    ... 1102000300 <=  *All Rel* 07/05 16:30:22 PASS
.- BadOwner                    ... 1102000300 <=  *All Rel* 07/05 16:30:22 PASS
.- StmtAuditOnCommit           ... 1102000300 <=  *All Rel* 07/05 16:30:22 PASS
.- BadPublicObjects            ... 1102000300 <=  *All Rel* 07/05 16:30:22 PASS
.- BadSegFreelist              ... 1102000300 <=  *All Rel* 07/05 16:30:22 PASS
.- BadDepends                  ... 1102000300 <=  *All Rel* 07/05 16:30:22 PASS
.- CheckDual                   ... 1102000300 <=  *All Rel* 07/05 16:30:23 PASS
.- ObjectNames                 ... 1102000300 <=  *All Rel* 07/05 16:30:23 WARN

HCKW-0018: OBJECT name clashes with SCHEMA name (Doc ID 2363142.1)
Schema=BSHRP INDEX=XFF.XFF

.- BadCboHiLo                  ... 1102000300 <=  *All Rel* 07/05 16:30:23 PASS
.- ChkIotTs                    ... 1102000300 <=  *All Rel* 07/05 16:30:24 PASS
.- NoSegmentIndex              ... 1102000300 <=  *All Rel* 07/05 16:30:24 PASS
.- BadNextObject               ... 1102000300 <=  *All Rel* 07/05 16:30:24 PASS
.- DroppedROTS                 ... 1102000300 <=  *All Rel* 07/05 16:30:24 PASS
.- FilBlkZero                  ... 1102000300 <=  *All Rel* 07/05 16:30:24 PASS
.- DbmsSchemaCopy              ... 1102000300 <=  *All Rel* 07/05 16:30:24 PASS
.- OrphanedObjError            ... 1102000300 >  1102000000 07/05 16:30:24 PASS
.- ObjNotLob                   ... 1102000300 <=  *All Rel* 07/05 16:30:24 PASS
.- MaxControlfSeq              ... 1102000300 <=  *All Rel* 07/05 16:30:24 PASS
.- SegNotInDeferredStg         ... 1102000300 >  1102000000 07/05 16:30:25 PASS
.- SystemNotRfile1             ... 1102000300 >   902000000 07/05 16:30:25 PASS
.- DictOwnNonDefaultSYSTEM     ... 1102000300 <=  *All Rel* 07/05 16:30:25 PASS
.- OrphanTrigger               ... 1102000300 <=  *All Rel* 07/05 16:30:25 PASS
.- ObjNotTrigger               ... 1102000300 <=  *All Rel* 07/05 16:30:25 PASS
---------------------------------------
05-7月 -2022 16:30:25  Elapsed: 7 secs
---------------------------------------
Found 0 potential problem(s) and 1 warning(s)
Contact Oracle Support with the output and trace file
to check if the above needs attention or not

PL/SQL 过程已成功完成。

有一个SCHEMA和对象名一样,这个不影响属于正常情况(客户创建了一个用户叫做XFF,然后有创建了一个XFF的对象),该数据库恢复至此基本上晚上,业务可以直接运行,不用做逻辑迁移