标签云
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 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,877)
- DB2 (22)
- MySQL (82)
- Oracle (1,703)
- 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备份恢复 (659)
- Oracle安装升级 (107)
- 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)
-
最近发表
- .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
- Oracle 19c 202607补丁(RUs+OJVM)-19.32
- Patch_SCN快速修复ORA-01555数据库open故障
- 快速处理 ORA-01210: data file header is media corrupt 故障
- ORA-00314: log 3 of thread 1, expected sequence# N doesn’t match 0
- 记录block 0损坏,数据文件大量坏块,使用不当数据库版本恢复等各种操作之后的故障处理
- 需要注意:dbv 检测controlfile可能不准
标签归档:kcbzibmlt_kcrsds_1
不当数据库恢复操作导致一个月数据丢失
今天分享一个本不该发生的故障,结果由于现场人员没有合适的判断导致客户丢失近一个月数据,事故经过大概是这样的
1. 客户数据库由于断电,启动之后报ORA-600 kcratr_scan_lastbwr错误
2026-09-03T11:22:58.998379+08:00 Beginning crash recovery of 2 threads parallel recovery started with 31 processes Thread 1: Recovery starting at checkpoint rba (logseq 37738 block 7724), scn 0 Thread 2: Recovery starting at checkpoint rba (logseq 43821 block 37937), scn 0 2026-09-03T11:22:59.158232+08:00 Started redo scan Hex dump of (file 20, block 2720) in trace file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_34049.trc Reading datafile '+DATA/ORCL/DATAFILE/undotbs01.dbf' for corrupt data at rdba: 0x05000aa0 (file 20, block 2720) Reread Not Encrypted (file 20, block 2720) found same data physically corrupt:No, logically corrupt:No, and is not expected version by upper layer. Write verification failed for File 20 Block 2720 (rdba 0x5000aa0) ***************************************************************** 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. ***************************************************************** Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_34049.trc (incident=430645): ORA-00600: internal error code, arguments: [kcratr_scan_lastbwr], [], [], [], [], [], [], [], [], [], [], [] Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl1/incident/incdir_430645/orcl1_ora_34049_i430645.trc 2026-09-03T11:23:00.484486+08:00 Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. 2026-09-03T11:23:00.510512+08:00 Slave encountered ORA-10388 exception during crash recovery
这个是一个比较常见的错误一般是由于redo写丢失导致(数据库open报ORA-600 kcratr_scan_lastbwr故障处理)
2. 现场操作的技术人员看了下这个错误,觉得数据库有备份,直接决定使用备份进行恢复

结果发现读取的是20260719的备份,而且原始的数据文件在asm里面,已经被覆盖。这个时候如果归档或者增量备份完整,还能够最大限度抢救数据,检查备份发现只有8月7日的增量备份,没有任何归档的备份(使用crontab 直接清理3天之前的归档)

基于这样的情况,应用到最后一个增量备份(也就是8月7日),后面的数据由于归档已经被清理(而且没有备份)

出现这个问题的原因是由于备份脚本本身备份归档,导致备份无法按照策略清理历史备份,导致磁盘空间满,从而后续备份无法继续(直接清理归档了)

恢复只能到此为止,查询最终的文件头恢复时间点

3. 基于这种情况只能尝试强制打开数据库,结果报ORA-600 kcbzibmlt_kcrsds_1错误
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: [kcbzibmlt_kcrsds_1], [], [], [] Process ID: 30365 Session ID: 2180 Serial number: 43414
4. 这种错误类似ORA-600 kcbzib_kcrsds_1的处理思路,使用obet的patch_scn功能直接进行处理
OBET> patch_scn 89103 0x60017e98 3182707622 === Oracle SCN Patch === PID: 89103 Address: 0x60017e98 New Value: 0xbdb443a6 (3182707622) Original SCN: 0x0 Are you sure you want to modify Oracle SCN? (yes/no): y SCN modified: 0x0 -> 0xbdb443a6 Oracle SCN successfully modified.
然后打开数据库
SQL> alter database open; Database altered.
导出数据,导入新库完成本次恢复任务,可惜没有办法帮客户找回来丢失的那一个月数据.
案例总结:
1. rman备份脚本尽量不要有直接删除归档的操作,尽可能是先备份然后再删除(确认备份成功之后删除)
2. 备份还原操作之前,需要看备份文件和日志,大概评估下备份的可用性
3. 尽可能不要在损坏的现场环境上直接做rman还原操作(万一备份无法正常还原,比如中途有备份文件异常呢?)
4. 这个故障,如果不做还原操作,直接异常恢复,基本上也就丢失了当前redo中的数据,损失是最小的
由于数据块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的错误

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

