标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 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-600 kdsgrp1 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 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (110)
- 数据库 (1,833)
- DB2 (22)
- MySQL (81)
- Oracle (1,662)
- 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 (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (628)
- Oracle安装升级 (103)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (88)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (47)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (30)
-
最近发表
- .wman扩展名勒索mysql数据库恢复
- Oracle数据库被勒索加密一键open工具–OraFHR
- 通过alert日志回顾其他dba oracle异常恢复故障处理以及后续open数据库操作
- 年前几例Oracle数据库被加密为.wman的数据库故障恢复
- 文件系统损坏导致数据库异常故障处理
- expdp导出xml列报ORA-22924故障处理
- obet处理ORA-704 ORA-604 ORA-1578故障
- obet修复csc higher than block scn类型坏块
- ORA-600 kcratr_nab_less_than_odr和ORA-600 4193故障处理
- aix环境10g由于控制器异常导致ORA-600 4000故障处理
- ORA-600 3716故障处理
- 不当恢复truncate数据导致数据库不能open处理
- 注意:PostgreSQL库出现readme_to_recover勒索
- Oracle 19c 202601补丁(RUs+OJVM)-19.30
- Patch_SCN快速解决ORA-600 2663故障
- 在生产环境错误执行dd命令破坏asm磁盘故障恢复
- obet实现对数据文件坏块检测功能
- oracle linux 8.10注意pmlogger导致空间被大量占用
- obet快速修改scn/resetlogs恢复数据库(缺少归档,ORA-00308)
- 使用DBMS_PDB.RECOVER抢救单个pdb
标签归档:kcbzib_kcrsds_1
由于数据块scn大于数据库scn导致ORA-600 kcbzib_kcrsds_1错误
以前遇到ORA-600 kcbzib_kcrsds_1一般都是数据库强制打开的时候,这次在一个open的库中遇到该问题,做一个记录
在expdp过程中有一个表报ORA-01555错误
. . 导出了 "SRM_DEV"."AAAAAA" 3.256 MB 4636 行 ORA-31693: 表数据对象 "SRM_DEV"."XXXXXXX" 无法加载/卸载并且被跳过, 错误如下: ORA-02354: 导出/导入数据时出错 ORA-01555: 快照过旧: 回退段号 (名称为 "") 过小
这种错误,根据以往经验,大部分情况是由于lob字段异常引起
查看表结构
SQL> desc "SRM_DEV"."XXXXXXX" 名称 是否为空? 类型 ----------------------------------------- -------- ---------------------------- DELIVERY_ID NOT NULL NUMBER(19) ARRIVAL_CUSTOMER_ID NUMBER(19) ARRIVAL_LOCATION_TYPE VARCHAR2(255 CHAR) ARRIVAL_SUPPLIER_ID NUMBER(19) ARRIVAL_TIME TIMESTAMP(6) ARRIVAL_USER NUMBER(19) CREATE_BY VARCHAR2(32 CHAR) CREATE_TIME TIMESTAMP(6) DELIVERY_DATE VARCHAR2(32 CHAR) DELIVERY_NO VARCHAR2(32 CHAR) DELIVERY_TYPE VARCHAR2(32 CHAR) INVOICE_TYPE VARCHAR2(2) IS_CONFIRM VARCHAR2(2) IS_ONEKEY_IO VARCHAR2(2) IS_SUPPORTING VARCHAR2(32 CHAR) MODI_BY VARCHAR2(32 CHAR) MODI_TIME TIMESTAMP(6) OP_ATTRIBUTE VARCHAR2(1 CHAR) PRINT_TIMES NUMBER(10) RECEIVE_COMPANY VARCHAR2(64 CHAR) RECEIVE_LOCATION VARCHAR2(64 CHAR) RECEIVE_SUPPLIER_ID NUMBER(19) REMARK VARCHAR2(256 CHAR) STATUS VARCHAR2(5 CHAR) SUPPLIER_CODE VARCHAR2(64 CHAR) SUPPLIER_ID NUMBER(19) OVERDUE_STATUS VARCHAR2(255 CHAR)
确认没有lob字段而引起了该问题,进一步分析
对表进行全扫描看看报什么错误
SQL> select /*+full(t)*/ count(1) from "SRM_DEV"."XXXXXXX" t;
select /*+full(t)*/ count(1) from "SRM_DEV"."XXXXXXX" t
*
第 1 行出现错误:
ORA-00600: 内部错误代码, 参数: [kcbzib_kcrsds_1], [], [], [], [], [], [],
[], [], [], [], []
根据以往经验,怀疑是由于这个表中的某个block的scn大于数据库scn导致
对全表扫描过程进行跟踪
C:\Users\Administrator>sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on 星期日 12月 21 22:18:46 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> oradebug setmypid
已处理的语句
SQL> alter session set db_file_multiblocK_read_count=1;
会话已更改。
SQL> oradebug EVENT 10046 TRACE NAME CONTEXT FOREVER, LEVEL 12
已处理的语句
SQL> oradebug TRACEFILE_NAME
F:\APP\diag\rdbms\srmdev\srmdev\trace\srmdev_ora_14768.trc
SQL>
SQL>
SQL> select /*+full(t)*/ count(1) from "SRM_DEV"."XXXXXXX" t;
select /*+full(t)*/ count(1) from "SRM_DEV"."XXXXXXX" t
*
第 1 行出现错误:
ORA-00600: 内部错误代码, 参数: [kcbzib_kcrsds_1], [], [], [], [], [], [],
[], [], [], [], []
分析trace文件确认对应的block为20548
WAIT #758663789368: nam='db file sequential read' ela= 40 file#=7 block#=20545 blocks=1 obj#=73756 tim=47881962193 WAIT #758663789368: nam='db file sequential read' ela= 41 file#=7 block#=20546 blocks=1 obj#=73756 tim=47881962259 WAIT #758663789368: nam='db file sequential read' ela= 40 file#=7 block#=20547 blocks=1 obj#=73756 tim=47881962325 WAIT #758663789368: nam='db file sequential read' ela= 41 file#=7 block#=20548 blocks=1 obj#=73756 tim=47881962389 Encountered exception while getting args for function:0x00007FF6F0BC39A0 2025-12-21T22:19:17.768815+08:00 Incident 1562659 created, dump file: F:\APP\diag\rdbms\srmdev\srmdev\incdir_1562659\srmdev_ora_14768_i1562659.trc ORA-00600: 内部错误代码, 参数: [kcbzib_kcrsds_1], [], [], [], [], [], [], [], [], [], [], []
对异常block进行dump分析
PARSE #758663744160:c=0,e=97,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=0,tim=48020763236
Start dump data blocks tsn: 4 file#:7 minblk 20548 maxblk 20548
Block dump from cache:
Dump of buffer cache at level 3 for pdb=0 tsn=4 rdba=29380676
WAIT #758663744160: nam='db file sequential read' ela= 88 file#=7 block#=20548 blocks=1 obj#=73756 tim=48020763396
Block dump from disk:
buffer tsn: 4 rdba: 0x01c05044 (7/20548)
scn: 0x6a37b2cb8 seq: 0x02 flg: 0x06 tail: 0x2cb80602
frmt: 0x02 chkval: 0xe203 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x000000B0A274D000 to 0x000000B0A274F000
B0A274D000 0000A206 01C05044 A37B2CB8 06020006 [....DP...,{.....]
B0A274D010 0000E203 001B0001 0001201C A37B2CB4 [......... ...,{.]
B0A274D020 00068000 00321F02 01C05001 00160010 [......2..P......]
B0A274D030 0409F0A2 010001A8 000C0776 00002001 [........v.... ..]
通过这里可以确认当前block的scn为0x6a37b2cb8==>28512562360
查询当前数据库scn
SQL> select CURRENT_SCN from v$database; CURRENT_SCN -------------- 28512556338
通过分析确认当前数据库的scn小于该block的scn,所以报ORA-600 kcbzib_kcrsds_1错误.解决该问题的方法有两种
1. 调整数据库是scn,让数据库的scn 大于该block scn即可
2. 通过把该block的scn修改小一些(目的就是数据库scn大于block scn)
通过处理之后实现表正常查询
SQL> alter system checkpoint;
系统已更改。
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
--------------------
28512563830
SQL> select /*+full(t)*/ count(1) from "SRM_DEV"."XXXXXXX" t;
COUNT(1)
--------------------
19560
对于这种情况除了ora-600 kcbzib_kcrsds_1的报错之外,还可能会遇到ora-600 kcbzibmlt_kcrsds_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; 数据库已更改。
然后安排导出数据,完成本次恢复任务.
CDM备份缺少归档打开数据库报ORA-600 kcbzib_kcrsds_1故障处理
有客户联系我们,说一个19c的库,由于产生归档较多在备份过程中把部分归档删除而导致没有备份成功,从而使得他们那边一个误操作需要恢复使用备份做不完全恢复,备份厂商进行恢复并尝试强制打开库报ORA-600 kcbzib_kcrsds_1错误

由于客户那边使用的是CDM方式备份,可以较快的准备出来一个新环境,观察客户在应用日志过程中,文件头的scn一直不变,怀疑文件头由于begin backup冻结,对其进行dump,发现确实做了hot backup操作,而且没有end backup


由于缺少归档,不完全恢复没有成功,begin backup 也无法正常结束,对于这种情况,先尝试调整到文件头最大的scn值,尝试打开库
SQL> alter database open resetlogs ; alter database open resetlogs * ERROR at line 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], [], [], [], [], [], [], [], [], [], [], [] Process ID: 3949615 Session ID: 5111 Serial number: 30040 --重启到mount状态 SQL> set numw 16 col CHECKPOINT_TIME for a40 set lines 150 set pages 1000 SELECT status, to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss') checkpoint_time,FUZZY,checkpoint_change#, count(*) ROW_NUM FROM v$datafile_header GROUP BY status, checkpoint_change#, to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss'),fuzzy ORDER BY status, checkpoint_change#, checkpoint_time;SQL> SQL> SQL> SQL> 2 3 4 5 6 STATUS CHECKPOINT_TIME FUZ CHECKPOINT_CHANGE# ROW_NUM ------- ---------------------------------------- --- ------------------ ---------------- ONLINE 2025-02-08 22:43:01 YES 15626238353558 56
打开库失败,只能找出来数据库最大的block中最大scn,然后调整文件头scn的值,实现数据库open
SQL> oradebug setmypid Statement processed. SQL> oradebug DUMPvar SGA kcsgscn_ SQL> kscn8 kcsgscn_ [060017E98, 060017EA0) = 00000000 00000000 SQL> oradebug DUMPvar SGA kcsgscn_ kscn8 kcsgscn_ [060017E98, 060017EA0) = 8CD9C896 00000E4D SQL> SQL> SQL> SQL> alter database open ; alter database open * ERROR at line 1: ORA-01113: file 1 needs media recovery ORA-01110: data file 1: '/cdmbak/db/xifenfei/ob_data_D-XIFENFEI-SYSTEM_FNO-1_t13930nd' SQL> recover database; Media recovery complete. SQL> alter database open; Database altered. SQL>
使用exp导出客户需要的表,完成本次恢复任务
对于ORA-600 kcbzib_kcrsds_1恢复的情况,以前有过大量恢复案例,修改数据库scn即可
kcbzib_kcrsds_1报错汇总
12C数据库报ORA-600 kcbzib_kcrsds_1故障处理
存储故障,强制拉库报ORA-600 kcbzib_kcrsds_1处理
Patch SCN工具一键恢复ORA-600 kcbzib_kcrsds_1
此类故障处理太多,不一一列举,解决这个错误之后,数据库open成功,然后安排逻辑迁移即可

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

