一次 PCIe 缓存卡损坏引发的 Oracle 数据库宕机恢复实录：ORA-00600 [kcbzib_kcrsds_1]

本文以一次真实的应急恢复案例为主线，结合实验环境的故障复现与处理步骤，完整梳理 ORA-00600 [kcbzib_kcrsds_1] 这一典型 bootstrap 报错的成因与解决思路。文中客户信息已做脱敏处理，数据库名、路径等均为示意。

一、案例背景

某媒体行业客户使用一台数据库一体机承载核心业务库，环境信息如下：

• 数据库版本：Oracle 19.11.0.0
• 部署形态：RAC 双实例（示意为 proddb1 / proddb2）
• 存储：ASM 磁盘组 +DATAC1
• 归档模式：非归档（NOARCHIVELOG）

某日，一体机上的一块 PCIe 缓存卡（闪存加速卡）发生硬件损坏，由于该卡处于 IO 写入路径上，缓存中尚未落盘的数据块丢失，直接导致数据库异常宕机。硬件处理完成后尝试拉起数据库，问题随之暴露。

这里有一个关键前提：数据库运行在非归档模式下。这意味着一旦联机重做日志（redo）或数据文件之间出现 SCN 不一致，没有归档日志可用于介质恢复——常规的 recover database 几乎无路可走，只能进入"强制拉库 + 抢救数据"的应急流程。

二、故障现象

数据库启动后，数据文件报需要介质恢复：

ERROR at line 1:
ORA-01113: file 11 needs media recovery
ORA-01110: data file 11: '+DATAC1/PRODDB/datafile2/tbs_upc0001.dbf'

非归档模式下没有归档日志可恢复，常规手段无法越过这一步，于是进入强制恢复阶段。

三、应急恢复全过程

⚠️ 风险提示：下文涉及大量 Oracle 隐含参数与 _allow_resetlogs_corruption 等强制手段，属于有损、不可逆的最后手段，仅适用于"数据库已无法正常打开、且无可用备份"的极端场景。生产环境操作前务必先做物理冷备（直接拷贝所有数据文件、控制文件、参数文件）。

1. 设置强制恢复相关参数

alter system set "_allow_resetlogs_corruption"=true scope=spfile;
alter system set "_allow_error_simulation"=true scope=spfile;
alter system set events '10513 trace name context forever,level 2';
-- 备份控制文件到 trace，用于后续重建
alter database backup controlfile to trace as '/tmp/ctl.txt';

其中 event 10513 level 2 的作用是禁止 SMON 进程做事务回滚，避免在拉库过程中因回滚动作触发新的崩溃。

2. 重建控制文件

由于控制文件信息与数据文件状态不再匹配，从 trace 中提取建库脚本，以 RESETLOGS 方式重建控制文件（数据文件清单较长，此处省略，保留结构）：

STARTUP NOMOUNT;

CREATE CONTROLFILE REUSE DATABASE "PRODDB" RESETLOGS FORCE LOGGING NOARCHIVELOG
    MAXLOGFILES 1024
    MAXLOGMEMBERS 5
    MAXDATAFILES 32767
    MAXINSTANCES 48
    MAXLOGHISTORY 33012
LOGFILE
    GROUP 1 '+DATAC1/PRODDB/ONLINELOG/group_101' SIZE 1024M BLOCKSIZE 512,
    GROUP 2 '+DATAC1/PRODDB/ONLINELOG/group_102' SIZE 1024M BLOCKSIZE 512,
    GROUP 13 '+DATAC1/PRODDB/ONLINELOG/group_103' SIZE 1024M BLOCKSIZE 512,
    GROUP 14 '+DATAC1/PRODDB/ONLINELOG/group_104' SIZE 1024M BLOCKSIZE 512
DATAFILE
    '+DATAC1/PRODDB/datafile2/system.dbf',
    '+DATAC1/PRODDB/datafile2/sysaux.dbf',
    '+DATAC1/PRODDB/datafile2/undotbs1.dbf',
    -- ……（此处省略其余业务数据文件）……
    '+DATAC1/PRODDB/datafile2/tbs_idxbd01.dbf'
CHARACTER SET ZHS16GBK
;

3. 打开数据库 —— 出现 ORA-00600 [kcbzib_kcrsds_1]

控制文件重建后尝试打开，报出本文主角：

ERROR at line 1:
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], [], [], [], [], [], [], [], [], [], [], []

ORA-00600 [kcbzib_kcrsds_1] 的本质：实例在 bootstrap（自举）阶段，需要用 redo 把数据文件恢复到一致状态，但此时缺失/不一致的 redo 导致 SCN 无法对齐，自举进程失败。在 redo 丢失的非归档库上，这是非常典型的报错。

4. 推进 SCN

设置 event 21307096（强制推进 SCN），并尝试用现存的联机日志做实例恢复：

# 在 pfile 中加入
event="21307096 trace name context forever, level 3"

SQL> recover database using backup controlfile until cancel;
-- 指定可用的联机日志成员进行恢复

恢复过程中会看到 redo 与 resetlogs SCN 不匹配的告警（ORA-00342、ORA-01194 等），属预期现象：

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '+DATAC1/PRODDB/datafile2/system.dbf'

5. 报错变化 —— SCN 推进成功的信号

再次尝试打开：

SQL> alter database open resetlogs upgrade;

ERROR at line 1:
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [4193], [4105], [4108], [], [], [], [], [], [], [], [], []

关键判断：报错从 [kcbzib_kcrsds_1] 变成了 [4193]。这说明 SCN 推进已经成功，bootstrap 阶段过去了，问题转移到了 undo（回滚段）层面——ORA-00600 [4193]/[4194]/[4197] 是一组典型的 redo / undo 记录不一致错误。

ORA-00600 [4194] 的参数含义：

• Arg [a]：Undo 块中记录的最大 Undo 记录数
• Arg [b]：Redo 块中的 Undo 记录数

两者不一致即触发该错误。

6. 重建 UNDO 表空间（参考 MOS Doc ID 1428786.1）

MOS 文档 Step by step to resolve ORA-600 4194 4193 4197 on database crash (Doc ID 1428786.1) 给出了标准处理流程，核心是用全新的 undo 表空间替换掉损坏的旧 undo。

Step 1：以手动 undo 管理方式启动到受限模式

在 pfile 中加入：

*.undo_management = manual
*.event = '10513 trace name context forever, level 2'

SQL> startup restrict pfile='/tmp/inittmp.ora';

Step 2：检查回滚段状态

SQL> select tablespace_name, status, segment_name
     from dba_rollback_segs where status != 'OFFLINE';

TABLESPACE_NAME      STATUS            SEGMENT_NAME
-------------------- ----------------- ------------------------------
SYSTEM               ONLINE            SYSTEM
UNDOTBS1             PARTLY AVAILABLE  _SYSSMU10_3568133130$

判断标准：除 SYSTEM 永远 ONLINE 外，其余 undo 段理想状态应全部 OFFLINE。若出现 PARTLY AVAILABLE 或 NEEDS RECOVERY，说明存在坏的回滚段，需要进一步处理。

Step 3：创建新的 undo 表空间

SQL> create undo tablespace undotbs7
     datafile '+DATAC1/PRODDB/datafile2/undotbs7.dbf' size 2000M;

Tablespace created.

Step 4：删除旧 undo —— 被活动回滚段阻塞

SQL> drop tablespace UNDOTBS1 including contents and datafiles;

ERROR at line 1:
ORA-01548: active rollback segment '_SYSSMU10_3568133130$' found,
terminate dropping tablespace

旧 undo 中仍有"活动"的坏回滚段，无法直接删除。解决办法是用隐含参数 _corrupted_rollback_segments 把它屏蔽掉：

# 在 pfile 中加入上一步查出的坏回滚段
*._corrupted_rollback_segments=(_SYSSMU10_3568133130$)

重启后再次删除，成功：

SQL> drop tablespace UNDOTBS1 including contents and datafiles;

Tablespace dropped.

Step 5：切换到新 undo 表空间

修改参数文件，将默认 undo 指向新建的表空间（去掉手动 undo 设置，恢复自动管理）：

*.undo_tablespace='UNDOTBS7'
#proddb2.undo_tablespace='UNDOTBS2'
#proddb1.undo_tablespace='UNDOTBS1'

7. 拉起数据库并抢救数据

SQL> startup pfile='/tmp/inittmp.ora' mount;
SQL> alter database open read only;

数据库最终以 只读（read only） 方式成功打开。考虑到这套库经历了强制 resetlogs、SCN 推进、undo 重建等一系列有损操作，数据库逻辑结构已不可信赖，因此最稳妥的收尾方式是：

立即用 expdp / exp 导出全部业务数据（dmp），在一套全新干净的数据库中重建并导入。

至此，客户核心数据成功抢救，业务得以在新库上恢复。

四、实验环境复现：从零造出 ORA-00600 [kcbzib_kcrsds_1]

为了更好地理解这个错误，可以在测试环境里主动复现。原理很简单：在非归档模式下，制造 redo 丢失 + 数据文件 fuzzy，然后强制 resetlogs。

测试环境：Oracle 19.3.0.0.0（non-CDB）。

Session 1：构造数据，让 buffer 中存在大量未落盘的变更

create user test123 identified by oracle;
grant dba to test123;

conn test123/oracle
create table t as select * from dba_objects;
insert into t select * from t;   -- 反复执行，快速放大数据量
/  -- 75040 rows
/  -- 150080 rows
/  -- 300160 rows
/  -- 600320 rows
/  -- 1200640 rows

Session 2：模拟"缓存卡损坏" —— 强杀实例 + 删除联机日志

# 找到并强杀 pmon，模拟实例突然崩溃（内存中脏数据丢失）
$ ps -ef | grep pmon
$ kill -9 <pmon_pid>

# 删除所有联机重做日志，模拟 redo 丢失
$ rm -rf redo0*

这一步本质上就是在还原案例中"PCIe 缓存卡损坏导致内存中数据丢失 + redo 不可用"的效果。

Session 3：复现报错

SQL> startup
Database mounted.
ORA-00313: open failed for members of log group 3 of thread 1
ORA-00312: online log 3 thread 1: '/oracle/.../redo03.log'
ORA-27037: unable to obtain file status

SQL> recover database until cancel;
-- 输入 cancel

ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/oracle/.../system01.dbf'

SQL> 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-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1], ...

完美复现。此时查询数据文件头，会看到所有文件 CHECKPOINT_CHANGE# 一致、但 FUZZY 均为 YES——正是 bootstrap 失败的根因特征：

SQL> select file#, fuzzy, to_char(CHECKPOINT_CHANGE#) from v$datafile_header;

     FILE# FUZ TO_CHAR(CHECKPOINT_CHANGE#)
---------- --- ---------------------------
         1 YES 2437336
         2 YES 2437336
         3 YES 2437336
         4 YES 2437336
         5 YES 2437336

后续处理与上文生产案例完全一致：设置 _allow_resetlogs_corruption、event 21307096 推进 SCN，报错转为 ORA-00600 [4194]，再按 Doc ID 1428786.1 重建 undo 表空间即可打开。

五、处理思路小结

整个恢复链条可以归纳为四步：

判断"是否在正确的方向上"的核心信号，就是 ORA-00600 后面的参数（错误码）是否在变化：从 kcbzib_kcrsds_1 → 4194，说明每一步强制手段都在生效。

六、经验与反思

1. 非归档模式是高危配置。一旦发生 redo 丢失，几乎没有"无损恢复"的可能，只能强制拉库抢数据。核心业务库务必开启归档。

2. 硬件缓存（写缓存/闪存加速卡）是一把双刃剑。它在提升性能的同时，把"内存中未落盘数据"的丢失风险放大。要么使用带掉电保护（电容/电池）的可靠缓存，要么对该路径上的数据库做好充分的备份冗余。

3. 备份才是底线。本案例之所以惊险，根因是缺少可用备份。RMAN 全备 + 归档 + 定期恢复演练，远比事后用隐含参数"赌一把"可靠。

4. 强制恢复后的库不可信。经过 _allow_resetlogs_corruption、SCN 推进、undo 重建的数据库，仅应作为"临时抢救数据的载体"，最终一定要逻辑导出后在干净环境重建，切勿继续用于生产。

5. 善用 MOS。ORA-00600 [4193]/[4194]/[4197] 这类错误，Oracle 官方文档（如 Doc ID 1428786.1）已有成熟流程，遇到时优先查 MOS、按官方步骤执行，比凭经验试探更安全。

免责声明：本文所有隐含参数与强制恢复手段均为最后手段，存在数据丢失风险，请勿在生产环境未做物理备份的情况下直接套用。如遇真实故障，建议先做冷备并联系原厂或专业服务支持。