标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-600 kcratr_nab_less_than_odr ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 ORACLE恢复 Oracle 恢复 ORACLE数据库恢复 oracle碎片 OSD-04016 YOUR FILES ARE ENCRYPTED 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,882)
- DB2 (22)
- MySQL (82)
- Oracle (1,707)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (72)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (661)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
- MongoDB (1)
-
最近发表
- 断电引起ORA-600 3005故障处理
- 记录一次云存储资源到期之后引起的数据库恢复
- Firebird 损坏数据库数据抢救工具—firebirdext
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于con$.con#值达到极限,触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
- 几乎动用了所有手段的Oracle故障恢复
- Oracle Block Edit Tool (obet) 功能增强–2026.07
分类目录归档:数据库
ORA-600 kcratr_nab_less_than_odr和ORA-600 2662故障处理
异常断电之后,oracle启动报ORA-600 kcratr_nab_less_than_odr错误
Sun Aug 17 11:06:09 2025 ALTER DATABASE OPEN Beginning crash recovery of 1 threads parallel recovery started with 11 processes Started redo scan Completed redo scan read 0 KB redo, 0 data blocks need recovery ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [40785], [33267], [40630] Sun Aug 17 11:06:20 2025 Aborting crash recovery due to error 600 Sun Aug 17 11:06:20 2025 Trace dumping is performing id=[cdmp_20250817110620] Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_2920.trc: ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [40785], [33267], [40630] Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_2920.trc: ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [40785], [33267], [40630] ORA-600 signalled during: ALTER DATABASE 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 kcratr_nab_less_than_odr和ORA-600 4194故障处理
一般重建ctl或者using backup ctl方式恢复即可实现0丢失打开库,但是这个库尝试打开报ORA-600 2662错误
SQL> startup nomount; ORACLE 例程已经启动。 Total System Global Area 6847938560 bytes Fixed Size 2188768 bytes Variable Size 4680845856 bytes Database Buffers 2147483648 bytes Redo Buffers 17420288 bytes SQL> @rectl.sql 控制文件已创建。 SQL> SQL> SQL> recover database; 完成介质恢复。 SQL> alter database open; alter database open * 第 1 行出现错误: ORA-00603: ORACLE server session terminated by fatal error ORA-00600: internal error code, arguments: [2662], [4413], [1200914792], [4413], [1201104184], [12583040], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [2662], [4413], [1200914791], [4413], [1201104184], [12583040], [], [], [], [], [], [] ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00600: internal error code, arguments: [2662], [4413], [1200914789], [4413], [1201104184], [12583040], [], [], [], [], [], [] 进程 ID: 3132 会话 ID: 3018 序列号: 1
对于这样的ORA-600 2662错误是比较常见的问题,直接通过Patch_SCN工具修改scn即可正常打开库

Mon Aug 18 03:30:41 2025
ALTER DATABASE RECOVER database
Media Recovery Start
started logmerger process
Parallel Media Recovery started with 12 slaves
Mon Aug 18 03:30:41 2025
Recovery of Online Redo Log: Thread 1 Group 2 Seq 40787 Reading mem 0
Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG
Completed: ALTER DATABASE RECOVER database
alter database open
Beginning crash recovery of 1 threads
parallel recovery started with 11 processes
Started redo scan
Completed redo scan
read 1 KB redo, 0 data blocks need recovery
Started redo application at
Thread 1: logseq 40787, block 2, scn 18954891612040
Recovery of Online Redo Log: Thread 1 Group 2 Seq 40787 Reading mem 0
Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG
Completed redo application of 0.00MB
Completed crash recovery at
Thread 1: logseq 40787, block 4, scn 18954891632047
0 data blocks read, 0 data blocks written, 1 redo k-bytes read
Mon Aug 18 03:30:47 2025
Thread 1 advanced to log sequence 40788 (thread open)
Thread 1 opened at log sequence 40788
Current log# 3 seq# 40788 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Mon Aug 18 03:30:47 2025
SMON: enabling cache recovery
Dictionary check beginning
Tablespace 'TEMP' #3 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
*********************************************************************
Database Characterset is ZHS16GBK
replication_dependency_tracking turned off (no async multimaster replication found)
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Completed: alter database open
后续增加tempfile,导出数据完成本次恢复任务
joxcsys: release mismatch, 19.0.0.0.0 1.8 in database (classes.bin)
expdp导出数据报ORA-39127 ORA-29548错误
ORA-39127: 调用 BEGIN :1 := SYS.DBMS_JAVA.START_EXPORT(:2, :3, :4, :5, :6, :7, :8, :9 ,:10); END; 时发生意外错误 ORA-29548: Java 系统类报告: release of Java system classes in the database (19.0.0.0.0 1.8) does not match that of the o racle executable (19.3.0.0.0 1.8) ORA-06512: 在 "SYS.DBMS_JAVA", line 520 ORA-06512: 在 line 1 ORA-06512: 在 "SYS.DBMS_JAVA", line 520 ORA-06512: 在 line 1 ORA-06512: 在 "SYS.DBMS_METADATA", line 11827 ORA-06512: 在 "SYS.DBMS_SYS_ERROR", line 95
对应的alert日志报错
2025-08-14T11:37:10.886745+08:00 joxcsys: release mismatch, 19.0.0.0.0 1.8 in database (classes.bin) vs 19.3.0.0.0 1.8 in executable pid 2624 cid 0 joxcsys: release mismatch, 19.0.0.0.0 1.8 in database (classes.bin) vs 19.3.0.0.0 1.8 in executable pid 2624 cid 0 2025-08-14T11:37:11.379211+08:00 Resize operation completed for file# 68, old size 83776K, new size 84800K Resize operation completed for file# 68, old size 84800K, new size 85824K 2025-08-14T11:37:12.333138+08:00 joxcsys: release mismatch, 19.0.0.0.0 1.8 in database (classes.bin) vs 19.3.0.0.0 1.8 in executable pid 2624 cid 0 joxcsys: release mismatch, 19.0.0.0.0 1.8 in database (classes.bin) vs 19.3.0.0.0 1.8 in executable pid 2624 cid 0 joxcsys: release mismatch, 19.0.0.0.0 1.8 in database (classes.bin) vs 19.3.0.0.0 1.8 in executable pid 2624 cid 0 joxcsys: release mismatch, 19.0.0.0.0 1.8 in database (classes.bin) vs 19.3.0.0.0 1.8 in executable pid 2624 cid 0
数据库版本(19.3版本,没有打任何其他patch)
C:\Users\Administrator>sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on 星期四 8月 14 11:17:08 2025 Version 19.3.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. 连接到: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.3.0.0.0
出现这个错误一般是由于Oracle JVM组件和Oracle JVM库不同步导致,对于这个初始版本(没有打任何patch),理论上不应该发生该问题,既然已经发生了,那就解决问题
SQL> startup upgrade;
ORACLE 例程已经启动。
Total System Global Area 1.5435E+10 bytes
Fixed Size 16124312 bytes
Variable Size 4563402752 bytes
Database Buffers 1.0838E+10 bytes
Redo Buffers 17428480 bytes
数据库装载完毕。
数据库已经打开。
SQL> alter system set java_jit_enabled = FALSE;
系统已更改。
SQL> alter system set "_system_trig_enabled"=FALSE;
系统已更改。
SQL> alter system set JOB_QUEUE_PROCESSES=0;
系统已更改。
SQL> create or replace java system
2 /
Java 已创建。
SQL> alter system set java_jit_enabled = true;
系统已更改。
SQL> alter system set "_system_trig_enabled"=TRUE;
系统已更改。
SQL> alter system set JOB_QUEUE_PROCESSES=100;
系统已更改。
SQL> @?/rdbms/admin/utlrp.sql
会话已更改。
TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_BGN 2025-08-14 12:42:59
……………………
PL/SQL 过程已成功完成。
SQL> SELECT dbms_java.longname('TEST') long_name FROM dual;
LONG_NAME
--------------------------------------------------------------------------------
TEST
SQL> shutdown immediate;
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup
ORACLE 例程已经启动。
Total System Global Area 1.5435E+10 bytes
Fixed Size 16124312 bytes
Variable Size 4563402752 bytes
Database Buffers 1.0838E+10 bytes
Redo Buffers 17428480 bytes
数据库装载完毕。
数据库已经打开。
如果有其他情况,具体参考:ORA-29548 Error While Running Java Code or Datapatch In Database (Doc ID 2934546.1)文档
win环境断电强制拉库报ORA-600 kcbzib_kcrsds_1故障处理
客户环境异常断电,导致数据库无法正常启动,执行recover提示缺少归档(ORA-00279 ORA-00289 ORA-00280错误)
C:\Users\Administrator>sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on 星期四 8月 14 11:17:08 2025
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle. All rights reserved.
连接到:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
SQL> select open_mode from v$database;
OPEN_MODE
----------------------------------------
MOUNTED
SQL> select group#,sequence#,status from v$log;
GROUP# SEQUENCE# STATUS
---------- ---------- --------------------------------
1 15082 ACTIVE
3 15084 CURRENT
2 15083 ACTIVE
SQL> recover database;
ORA-00279: 更改 885427209 (在 08/11/2025 22:14:56 生成) 对于线程 1 是必需的
ORA-00289: 建议:
D:\APP\ADMINISTRATOR\PRODUCT\19.0.0\DBHOME_1\RDBMS\ARC0000015080_1051367880.0001
ORA-00280: 更改 885427209 (用于线程 1) 在序列 #15080 中
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00308: 无法打开归档日志
'D:\APP\ADMINISTRATOR\PRODUCT\19.0.0\DBHOME_1\RDBMS\ARC0000015080_1051367880.0001'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
z这个库需要15080归档,但是由于非归档环境,redo最小为15082,所以这种情况,只能先恢复可以正常recover的数据文件,然后强制拉库
SQL> recover datafile 1;
完成介质恢复。
SQL> recover datafile 3,4,7;
完成介质恢复。
SQL> recover datafile 62;
完成介质恢复。
SQL> recover database until cancel;
ORA-00279: 更改 885427209 (在 08/11/2025 22:14:56 生成) 对于线程 1 是必需的
ORA-00289: 建议:
D:\APP\ADMINISTRATOR\PRODUCT\19.0.0\DBHOME_1\RDBMS\ARC0000015080_1051367880.0001
ORA-00280: 更改 885427209 (用于线程 1) 在序列 #15080 中
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01152: 文件 1 没有从过旧的备份中还原
ORA-01110: 数据文件 1: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\SYSTEM01.DBF'
ORA-01112: 未启动介质恢复
SQL> alter database open resetlogs ;
alter database open resetlogs
*
第 1 行出现错误:
ORA-00603: ORACLE server session terminated by fatal error
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1], [], [], [], [],
[], [], [], [], [], [], []
进程 ID: 6272
会话 ID: 3873 序列号: 46847
alert日志报错
2025-08-14T11:24:08.246798+08:00 alter database open resetlogs 2025-08-14T11:24:08.425971+08:00 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_mz00_7464.trc: ORA-01110: 数据文件 28: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\PRESCRIPTION_P.DBF' 2025-08-14T11:24:08.643178+08:00 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_mz00_7464.trc: ORA-01110: 数据文件 29: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\PRESCRIPTION_DETAIL_P.DBF' 2025-08-14T11:24:08.958486+08:00 RESETLOGS is being done without consistancy checks. This may result in a corrupted database. The database should be recreated. RESETLOGS after incomplete recovery UNTIL CHANGE 885427209 time Resetting resetlogs activation ID 3572089731 (0xd4e9c383) 2025-08-14T11:24:08.988512+08:00 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_mz00_7464.trc: ORA-01110: 数据文件 30: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\ORDER_LIST_P.DBF' 2025-08-14T11:24:12.029432+08:00 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_mz00_7464.trc: ORA-01110: 数据文件 31: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\CHARGE_STATIS_P.DBF' 2025-08-14T11:24:13.687023+08:00 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_mz00_7464.trc: ORA-01110: 数据文件 32: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\ECASETAB01.DBF' 2025-08-14T11:24:13.725060+08:00 Setting recovery target incarnation to 2 Checker run found 31 new persistent data failures 2025-08-14T11:24:14.701994+08:00 Ping without log force is disabled: instance mounted in exclusive mode. Endian type of dictionary set to little 2025-08-14T11:24:14.793084+08:00 Assigning activation ID 3729861866 (0xde512cea) 2025-08-14T11:24:14.848137+08:00 TT00 (PID:8068): Gap Manager starting 2025-08-14T11:24:14.870158+08:00 Redo log for group 1, sequence 1 is not located on DAX storage Thread 1 opened at log sequence 1 Current log# 1 seq# 1 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\HIS\REDO01.LOG Successful open of redo thread 1 2025-08-14T11:24:14.912199+08:00 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set stopping change tracking 2025-08-14T11:24:15.849098+08:00 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_ora_6272.trc(incident=717057): ORA-00600: 内部错误代码, 参数: [kcbzib_kcrsds_1], [], [], [], [], [], [], [], [], [], [], [] Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Please look for redo dump in pinned buffers history in incident trace file, if not dumped for what so ever reason, use the following command to dump it at the earliest. ALTER SYSTEM DUMP REDO DBA MIN 4 128 DBA MAX 4 128 SCN MIN 1; 2025-08-14T11:24:17.402582+08:00 ***************************************************************** An internal routine has requested a dump of selected redo. This usually happens following a specific internal error, when analysis of the redo logs will help Oracle Support with the diagnosis. It is recommended that you retain all the redo logs generated (by all the instances) during the past 12 hours, in case additional redo dumps are required to help with the diagnosis. ***************************************************************** Undo initialization recovery: err:600 start: 2392187 end: 2394046 diff: 1859 ms (1.9 seconds) 2025-08-14T11:24:17.528703+08:00 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_ora_6272.trc: ORA-00600: 内部错误代码, 参数: [kcbzib_kcrsds_1], [], [], [], [], [], [], [], [], [], [], [] 2025-08-14T11:24:17.529703+08:00 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_ora_6272.trc: ORA-00600: 内部错误代码, 参数: [kcbzib_kcrsds_1], [], [], [], [], [], [], [], [], [], [], [] Error 600 happened during db open, shutting down database Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_ora_6272.trc(incident=717058): ORA-00603: ORACLE 服务器会话因致命错误而终止 ORA-01092: ORACLE 实例终止。强制断开连接 ORA-00600: 内部错误代码, 参数: [kcbzib_kcrsds_1], [], [], [], [], [], [], [], [], [], [], [] 2025-08-14T11:24:18.995110+08:00 opiodr aborting process unknown ospid (6272) as a result of ORA-603 2025-08-14T11:24:18.997112+08:00 ORA-603 : opitsk aborting process License high water mark = 42 USER (ospid: (prelim)): terminating the instance due to ORA error 2025-08-14T11:24:23.749679+08:00 Instance terminated by USER(prelim), pid = 6272
遭遇到比较明显的ORA-600 kcbzib_kcrsds_1错误,通过自研的Patch_SCN小工具,以前有过类似恢复案例:
Patch SCN工具一键恢复ORA-600 kcbzib_kcrsds_1

然后直接open数据库
SQL> recover database; 完成介质恢复。 SQL> oradebug setmypid 已处理的语句 SQL> oradebug DUMPvar SGA kcsgscn_ kscn8 kcsgscn_ [7FF6623FF310, 7FF6623FF318) = 40B272E2 00000000 SQL> SQL> alter database open; 数据库已更改。
然后安排导出数据,完成本次恢复任务.

加我微信(17813235971)
加我QQ(107644445)

