标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 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-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)
- 操作系统 (103)
- 数据库 (1,738)
- DB2 (22)
- MySQL (75)
- Oracle (1,588)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (160)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (68)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (582)
- Oracle安装升级 (95)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (83)
- PostgreSQL (27)
- pdu工具 (5)
- PostgreSQL恢复 (9)
- SQL Server (29)
- SQL Server恢复 (10)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- ORA-39773: parse of metadata stream failed故障处理
- sql数据库备份失败—失败: 23(数据错误(循环冗余检查)
- vmdk文件被加密恢复(虚拟机文件加密)
- 差点被误操作的ORA-600 kcratr_nab_less_than_odr故障
- win平台19c 打patch遭遇2个小问题汇总
- pg单个数据库目录恢复-pdu恢复单个数据库目录数据
- pg删除数据恢复—pdu恢复pg delete数据
- .[OnlyBuy@cyberfear.com].REVRAC勒索mysql恢复
- 表dml操作权限授权给public,导致只读用户失效
- 21c数据库恢复遭遇ora-600 ktugct: corruption detected
- pg_control丢失/损坏处理
- 当前主流数据库版本服务支持周期-202503
- pg启动报invalid checkpoint record处理
- 删除redo导致ORA-00313 ORA-00312故障处理
- Navicat连接postgresql时出现column “datlastsysoid” does not exist错误解决
- aix磁盘损坏oracle数据库恢复
- pg误删除数据恢复(PostgreSQL delete数据恢复)
- PostgreSQL表文件损坏恢复—pdu恢复损坏的表文件
- linux rm -rf 删除数据文件恢复
- PostgreSQL恢复工具—pdu恢复单个表文件
标签归档:kcbzib_kcrsds_1
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成功,然后安排逻辑迁移即可
2025年首个故障恢复—ORA-600 kcbzib_kcrsds_1
一个12.2.0.1的库由于某种原因引起的双机切换,导致数据库无法正常mount
2025-01-04T15:45:44.424193+08:00 alter database mount 2025-01-04T15:45:48.491054+08:00 Network throttle feature is disabled as mount time 2025-01-04T15:45:48.601366+08:00 LGWR (ospid: 34014): terminating the instance 2025-01-04T15:45:48.602480+08:00 System state dump requested by (instance=1, osid=34014 (LGWR)), summary=[abnormal instance termination]. System State dumped to trace file /u01/app/oracle/diag/rdbms/xifenfei/trace/xifenfei_diag_33978_20250104154548.trc 2025-01-04T15:45:48.790674+08:00 Dumping diagnostic data in directory=[cdmp_20250104154548], requested by (instance=1, osid=34014 (LGWR)) 2025-01-04T15:45:49.915068+08:00 Instance terminated by LGWR, pid = 34014
这个错误相对比较明显,是由于ctl异常导致,通过重建ctl,然后mount库,利用Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)脚本进行检测发现所有数据文件头的checkpoint 信息被冻结在 2024-11-29 19:00:29 (scn 2112302221)
分析alert日志数据库在此后20天中正常提供服务,业务运行都正常,客户反馈在这个冻结checkpoint信息的时间点,使用备份一体机发起过备份,之后就没有再备份了.
当时急着恢复数据库,没有对文件头进行dump不然应该可以发现类似begin backup的信息,类似这样(测试环境重现):
DATA FILE #1: name #7: /u01/app/oracle/oradata/xifenfei/system01.dbf creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1 tablespace 0, index=1 krfil=1 prev_file=0 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00 Checkpoint cnt:625 scn: 0x0105.0106deef 01/04/2025 22:02:50 Stop scn: 0xffff.ffffffff 12/14/2024 08:15:07 Creation Checkpointed at scn: 0x0000.00000007 08/24/2013 11:37:33 thread:0 rba:(0x0.0.0) enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Offline scn: 0x0000.000e2005 prev_range: 0 Online Checkpointed at scn: 0x0000.000e2006 03/20/2024 20:53:56 thread:1 rba:(0x1.2.0) enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Hot Backup end marker scn: 0x0000.00000000 aux_file is NOT DEFINED Plugged readony: NO Plugin scnscn: 0x0000.00000000 Plugin resetlogs scn/timescn: 0x0000.00000000 01/01/1988 00:00:00 Foreign creation scn/timescn: 0x0000.00000000 01/01/1988 00:00:00 Foreign checkpoint scn/timescn: 0x0000.00000000 01/01/1988 00:00:00 Online move state: 0 V10 STYLE FILE HEADER: Compatibility Vsn = 186647552=0xb200400 Db ID=1780931490=0x6a26dba2, Db Name='XIFENFEI' Activation ID=0=0x0 Control Seq=32953021=0x1f6d2bd, File size=98560=0x18100 File Number=1, Blksiz=8192, File Type=3 DATA Tablespace #0 - SYSTEM rel_fn:1 Creation at scn: 0x0000.00000007 08/24/2013 11:37:33 Backup taken at scn: 0x0105.0106deef 01/04/2025 22:02:50 thread:1 <====注意 reset logs count:0x45636764 scn: 0x0000.000e2006 prev reset logs count:0x3121c97a scn: 0x0000.00000001 recovered at 12/14/2024 08:36:35 status:0x2001 root dba:0x00400208 chkpt cnt: 625 ctl cnt:624 begin-hot-backup file size: 98560 <====注意 Checkpointed at scn: 0x0105.0106deef 01/04/2025 22:02:50 thread:1 rba:(0x205.fdd9.10) enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Backup Checkpointed at scn: 0x0105.0106df14 01/04/2025 22:03:20 <====注意 thread:1 rba:(0x209.2.10) enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 External cache id: 0x0 0x0 0x0 0x0 Absolute fuzzy scn: 0x0000.00000000 Recovery fuzzy scn: 0x0000.00000000 01/01/1988 00:00:00 Terminal Recovery Stamp 01/01/1988 00:00:00 Platform Information: Creation Platform ID: 13 Current Platform ID: 13 Last Platform ID: 13
基于上述情况,尝试强制打开库,报ORA-00600: internal error code, arguments: [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成功,然后安排逻辑迁移即可
19c库启动报ORA-600 kcbzib_kcrsds_1
一套19c的库由于某种情况,发现异常,当时的技术使用隐含参数强制拉库,导致数据库启动报ORA-00704 ORA-600 kcbzib_kcrsds_1错误
2024-08-24T06:11:25.494304+08:00 ALTER DATABASE OPEN 2024-08-24T06:11:25.494370+08:00 TMI: adbdrv open database BEGIN 2024-08-24 06:11:25.494324 Smart fusion block transfer is disabled: instance mounted in exclusive mode. 2024-08-24T06:11:25.515306+08:00 Beginning crash recovery of 1 threads parallel recovery started with 7 processes Thread 1: Recovery starting at checkpoint rba (logseq 2 block 3), scn 286550073 2024-08-24T06:11:25.567011+08:00 Started redo scan 2024-08-24T06:11:25.587170+08:00 Completed redo scan read 0 KB redo, 0 data blocks need recovery 2024-08-24T06:11:25.595192+08:00 Started redo application at Thread 1: logseq 2, block 3, offset 0, scn 0x0000000011146839 2024-08-24T06:11:25.595552+08:00 Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0 Mem# 0: /dbf/RLZY/redo02.log 2024-08-24T06:11:25.595712+08:00 Completed redo application of 0.00MB 2024-08-24T06:11:25.596058+08:00 Completed crash recovery at Thread 1: RBA 2.3.0, nab 3, scn 0x000000001114683a 0 data blocks read, 0 data blocks written, 0 redo k-bytes read Endian type of dictionary set to little 2024-08-24T06:11:25.648152+08:00 LGWR (PID:1614826): STARTING ARCH PROCESSES 2024-08-24T06:11:25.661738+08:00 TT00 (PID:1614908): Gap Manager starting Starting background process ARC0 2024-08-24T06:11:25.677246+08:00 ARC0 started with pid=54, OS id=1614910 2024-08-24T06:11:25.687525+08:00 LGWR (PID:1614826): ARC0: Archival started LGWR (PID:1614826): STARTING ARCH PROCESSES COMPLETE 2024-08-24T06:11:25.687733+08:00 ARC0 (PID:1614910): Becoming a 'no FAL' ARCH ARC0 (PID:1614910): Becoming the 'no SRL' ARCH 2024-08-24T06:11:25.696437+08:00 TMON (PID:1614886): STARTING ARCH PROCESSES Starting background process ARC1 2024-08-24T06:11:25.711645+08:00 Thread 1 advanced to log sequence 3 (thread open) Redo log for group 3, sequence 3 is not located on DAX storage 2024-08-24T06:11:25.715270+08:00 ARC1 started with pid=56, OS id=1614914 Starting background process ARC2 Thread 1 opened at log sequence 3 Current log# 3 seq# 3 mem# 0: /dbf/RLZY/redo03.log Successful open of redo thread 1 2024-08-24T06:11:25.728586+08:00 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Stopping change tracking 2024-08-24T06:11:25.734124+08:00 ARC2 started with pid=57, OS id=1614916 Starting background process ARC3 2024-08-24T06:11:25.752891+08:00 ARC3 started with pid=58, OS id=1614918 2024-08-24T06:11:25.752979+08:00 TMON (PID:1614886): ARC1: Archival started TMON (PID:1614886): ARC2: Archival started TMON (PID:1614886): ARC3: Archival started TMON (PID:1614886): STARTING ARCH PROCESSES COMPLETE 2024-08-24T06:11:25.802551+08:00 ARC0 (PID:1614910): Archived Log entry 2828 added for T-1.S-2 ID 0x74f18f91 LAD:1 2024-08-24T06:11:25.806845+08:00 TT03 (PID:1614922): Sleep 5 seconds and then try to clear SRLs in 2 time(s) Errors in file /oracle/diag/rdbms/xff/xff/trace/xff_ora_1614892.trc (incident=124865): ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1], [], [], [], [], [], [], [], [], [], [], [] Incident details in: /oracle/diag/rdbms/xff/xff/incident/incdir_124865/xff_ora_1614892_i124865.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. 2024-08-24T06:11:25.871925+08:00 2024-08-24T06:11:26.772652+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. ***************************************************************** 2024-08-24T06:11:26.872265+08:00 Errors in file /oracle/diag/rdbms/xff/xff/trace/xff_ora_1614892.trc: ORA-00704: bootstrap process failure ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1], [], [], [], [], [], [], [], [], [], [], [] 2024-08-24T06:11:26.872351+08:00 Errors in file /oracle/diag/rdbms/xff/xff/trace/xff_ora_1614892.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1], [], [], [], [], [], [], [], [], [], [], [] 2024-08-24T06:11:26.872412+08:00 Errors in file /oracle/diag/rdbms/xff/xff/trace/xff_ora_1614892.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1], [], [], [], [], [], [], [], [], [], [], [] 2024-08-24T06:11:26.872455+08:00 Error 704 happened during db open, shutting down database Errors in file /oracle/diag/rdbms/xff/xff/trace/xff_ora_1614892.trc (incident=124866): ORA-00603: ORACLE server session terminated by fatal error ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1], [], [], [], [], [], [], [], [], [], [], [] Incident details in: /oracle/diag/rdbms/xff/xff/incident/incdir_124866/xff_ora_1614892_i124866.trc opiodr aborting process unknown ospid (1614892) as a result of ORA-603 2024-08-24T06:11:27.498146+08:00 Errors in file /oracle/diag/rdbms/xff/xff/trace/xff_ora_1614892.trc: ORA-00603: ORACLE server session terminated by fatal error ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1], [], [], [], [], [], [], [], [], [], [], [] 2024-08-24T06:11:27.501122+08:00 ORA-603 : opitsk aborting process License high water mark = 8 USER(prelim) (ospid: 1614892): terminating the instance due to ORA error 704 2024-08-24T06:11:28.526358+08:00 Instance terminated by USER(prelim), pid = 1614892
官方关于kcbzib_kcrsds_1从解释只有:Bug 31887074 – sr21.1bigscn_hipu3 – trc – ksfdopn2 – ORA-600 [kcbzib_kcrsds_1] (Doc ID 31887074.8)
虽然关于ORA-600 [kcbzib_kcrsds_1],oracle官方没有给出来解决方案,其实通过以往大量的恢复案例和经验中已经知道,这个错误解决方案就是修改oracle scn的方法可以绕过去,以前有过一些类似恢复案例:
ORA-600 kcbzib_kcrsds_1报错
12C数据库报ORA-600 kcbzib_kcrsds_1故障处理
ORA-00603 ORA-01092 ORA-600 kcbzib_kcrsds_1
redo异常强制拉库报ORA-600 kcbzib_kcrsds_1修复
Patch SCN工具一键恢复ORA-600 kcbzib_kcrsds_1
存储故障,强制拉库报ORA-600 kcbzib_kcrsds_1处理