108-ORA-00600 [kdsgrp1-qetlbr] 内部错误排查与 RMAN 块级恢复

1、故障背景

一个工作日的下午，存储双控同时丢包，控制器轮流掉线，数据库系统出现卡顿，CDR 平台直接crush，PDB 环境 CDR50 开始发现 alert 日志持续报出内部错误。实例为 Oracle 19c 19.24，采用 CDB 架构，承载核心业务表 DC_EXAM_REQUEST。

先说故障症状原因，节约浏览时间

本次故障由两个根因叠加触发：数据块逻辑损坏 + 索引与表数据不一致。RMAN 全库验证未发现物理坏块，但特定数据块在一致性读取时触发了 KDS（Kernel Data Segment）层内部错误。

2、错误现象：Alert 日志

登录服务器 X.X.0.104，查看 alert 日志：

bash 复制代码

[oracle@cdb-104]:~$ tail -100 /u01/app/oracle/diag/rdbms/cdrcdb/cdrcdb/trace/alert_cdrcdb.log

Errors in file /u01/app/oracle/diag/rdbms/cdrcdb/cdrcdb/trace/cdrcdb_ora_24077.trc:
ORA-00600: internal error code, arguments: [kdsgrp1-qetlbr], [6], [86110356], [4], [], [], [], [], [], [], [], []

CDR50(3):Incident details in: /u01/app/oracle/diag/rdbms/cdrcdb/cdrcdb/incident/incdir_361360/cdrcdb_ora_24077_i361360.trc

*** 2025-08-31T08:27:19.123+08:00
*** 2025-08-31T08:27:19.123+08:00 [CDR50] (3):
*** 2025-08-31T08:27:19.123+08:00 (3):Incident 361360 created, dump file: cdrcdb_ora_24077_i361360.trc

ORA-00600 是 Oracle 的通用内部错误信号，第一个参数 $kdsgrp1-qetlbr$ 指明了出错的函数位置------KDSGRP1（Kernel Data Segment Get Row Piece 1），即数据段读取行片段时发生异常。

3、错误参数解读

完整错误信息如下：

bash 复制代码

ORA-00600: internal error code, arguments: [kdsgrp1-qetlbr], [6], [86110356], [4], [], [], [], [], [], [], [], []

|-------|----------------|---------------------------------------------------------|
| 位置 | 值 | 含义 |
| Arg 1 | kdsgrp1-qetlbr | 错误函数标识：KDS 层读取行片段失败，调用来源为 QETLBR（行级别一致性读） |
| Arg 2 | 6 | 表空间编号（Tablespace Number） |
| Arg 3 | 86110356 | 相对数据块地址（RDBA, Relative Data Block Address），需转换为文件号 + 块号 |
| Arg 4 | 4 | 块内行槽位号（Row Slot / Slot Index），指向具体某一行 |

4、原因分析

查阅MOS资料kdsgrp1 错误通常由以下几类原因触发，本次故障为前两项叠加：

数据块逻辑损坏--此次大概率是主控故障中招

Buffer Cache 中的块在一致性读时发现数据不一致（如 ITL 槽位异常、行片链接断裂），或磁盘上的块存在逻辑层面的损坏，导致数据库无法正确组装行数据。

索引与表数据不一致

查询通过索引访问路径定位行，但索引条目指向的 ROWID 在表中不存在或位置偏移。此类问题在全文检索（CONTAINS）、位图索引或高并发 DML 场景下尤为常见。

Buffer Cache 内存异常

内存中的数据块被意外篡改或 LRU 刷新异常，重启后可能自行恢复。

Oracle 已知 Bug--未触发

特定版本在并行 DML、闪回查询、一致性读等场景下存在已知缺陷。

数据块故障模拟图

5、排查过程

5.1 从 trace 文件提取文件号与块号

根据 alert 日志中的 incident 路径，打开 trace 文件 cdrcdb_ora_24077_i361360.trc，定位到具体的数据文件号和块号：

bash 复制代码

*** 2025-08-31T08:27:19.123+08:00
kdedem: KDSGRP1 (4) args: 6 86110356 4
----- Current SQL Statement for this session (sql_id=7v2kf8m3n4x5y) -----
SELECT * FROM NHIP_DC.DC_EXAM_REQUEST WHERE EXAM_DATE >= :1 ...

Buffer block dump:
buffer dba: 0x05205534  file#: 20  block#: 2224276
Block header dump:  rdba: 0x05205534
  Object id on Block? Y
  seg/obj: 0x1a2f3  seg: 0x1a2e4  obj: 0x1a2f3
  scn: 0x3471827631  log: none  lod: 0
  Loaded vs Unloaded scn: 0x3471827631 / 0x3471827631

RDBA 换算

十进制 86110356 转十六进制为 0x05205534。根据 Oracle RDBA 编码规则（前10位为相对文件号，后22位为块号），可拆出 file# = 20，block# = 2224276。trace 文件中的 Buffer block dump 直接给出了结果，无需手工换算。

5.2 定位问题所属对象

切换到 PDB CDR50，查询该块属于哪个段：

bash 复制代码

[oracle@cdb-104]:~$ sql / as sysdba

SQLcl: Release 21.4 Production on Sun Aug 31 08:27:19 2025
Copyright (c) 1982, 2025, Oracle.  All rights reserved.

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.24.0.0.0

SYS@CDB$ROOT> show pdbs;

    CON_ID   CON_NAME   OPEN MODE   RESTRICTED
_________ __________ ___________ ______________
        2 PDB$SEED   READ ONLY   NO
        3 CDR50      READ WRITE  NO

SYS@CDB$ROOT> alter session set container=cdr50;

Session altered.

SYS@CDB$ROOT> SELECT owner, segment_name, segment_type, partition_name
  2  FROM dba_extents
  3  WHERE file_id = 20
  4    AND 2224276 BETWEEN block_id AND block_id + blocks - 1;

     OWNER      SEGMENT_NAME       SEGMENT_TYPE     PARTITION_NAME
__________ _________________ __________________ _________________
NHIP_DC    DC_EXAM_REQUEST    TABLE PARTITION    EXAM_REQUEST_M

SYS@CDB$ROOT>

目标对象确认：NHIP_DC.DC_EXAM_REQUEST 的分区 EXAM_REQUEST_M（月分区表）。

5.3 验证对象结构完整性

对目标表及其关联索引执行结构校验，确认是否存在逻辑不一致：

bash 复制代码

SYS@CDB$ROOT> ANALYZE TABLE NHIP_DC.DC_EXAM_REQUEST VALIDATE STRUCTURE CASCADE ONLINE;

Table analyzed.

SYS@CDB$ROOT> ANALYZE TABLE NHIP_DC.EXAM_REQUEST_M VALIDATE STRUCTURE CASCADE ONLINE;

Table analyzed.

-- 未报出 ROWID 不匹配或索引条目缺失，说明逻辑层面结构基本完整。

5.4 RMAN 物理验证数据文件

使用 RMAN 对数据文件 20 执行逻辑验证，检查是否存在坏块：

bash 复制代码

[oracle@cdb-104]:~$ rman target /

Recovery Manager: Release 21.0.0.0.0 - Production on Sun Aug 31 08:30:00 2025

Copyright (c) 1982, 2025, Oracle and/or its affiliates.  All rights reserved.

connected to target database: CDRCDB (DBID=1234567890)

RMAN> VALIDATE DATAFILE 20 CHECK LOGICAL;

Starting validate at 31-AUG-25
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=2362 device type=DISK
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=00020 name=/oradata/CDRCDB/cdr50/NHIP_DC20250226.dbf
channel ORA_DISK_1: validation complete, elapsed time: 00:01:25

List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
20   OK     0              1767176      4096000         3471827631
  File Name: /oradata/CDRCDB/cdr50/NHIP_DC20250226.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              407759
  Index      0              238107
  Other      0              1682958

Finished validate at 31-AUG-25

RMAN>

RMAN VALIDATE 报告 Marked Corrupt = 0，所有块 Failing = 0。这说明磁盘上的数据文件物理层面没有坏块------问题属于逻辑不一致（可能是内存块在某次一致读时状态异常，或索引条目与表行在 SCN 维度上存在错位）。

6、RMAN 块级恢复

尽管 RMAN 全文件验证未报物理坏块，但我们仍可对出错的具体块执行 BLOCK RECOVER，利用备份中的干净镜像重建该数据块，消除内存与磁盘间的逻辑不一致。

bash 复制代码

RMAN> RECOVER DATAFILE 20 BLOCK 2224276;

Starting recover at 31-AUG-25
using channel ORA_DISK_1

starting media recovery
channel ORA_DISK_1: restoring block(s) from datafile backup piece
channel ORA_DISK_1: media recovery complete, elapsed time: 00:00:00

media recovery complete, elapsed time: 00:00:00

Finished recover at 31-AUG-25

RMAN>

恢复成功

块级恢复在 1 秒内完成，仅重算了这一个块的变更向量（redo apply），不需要将数据文件 offline，对业务无感知。相比整文件恢复，块级恢复将影响范围降到了最低。

7、验证与收尾

恢复完成后，持续观察 alert 日志确认错误不再复现：

bash 复制代码

[oracle@cdb-104]:~$ tail -f /u01/app/oracle/diag/rdbms/cdrcdb/cdrcdb/trace/alert_cdrcdb.log

-- 持续观察 24 小时，无新的 ORA-00600 报错
-- 业务侧查询 NHIP_DC.DC_EXAM_REQUEST 正常返回结果
== 故障已消除，块级恢复生效 ==

同时建议对该表关联的索引执行重建或校验，以排除索引与表数据不一致的残留影响：

bash 复制代码

SYS@CDB$ROOT> -- 检查表索引条目与表行是否匹配
SYS@CDB$ROOT> ANALYZE TABLE NHIP_DC.DC_EXAM_REQUEST VALIDATE STRUCTURE CASCADE;

Table analyzed.

-- 如发现索引不一致，可在线重建索引：
-- ALTER INDEX NHIP_DC.IDX_EXAM_REQUEST_01 REBUILD ONLINE;

TIPS：

定期执行 RMAN VALIDATE：每周对核心数据文件做一次逻辑验证，提前发现坏块。
关注 ORA-00600 的第一个参数：kdsgrp1、ktsshrf、kdstblscan 等后缀直接指向故障子系统。
块级恢复优先于整文件恢复：只要有备份可用，BLOCK RECOVER 是影响最小的修复手段。
修复后持续观察 24 小时：逻辑损坏类问题可能存在"恢复后复现"的情况，需监控确认。