1、故障背景：存储迁移遗留问题
本案例是上一篇 108-ORA-00600 [kdsgrp1-qetlbr] 内部错误排查与 RMAN 块级恢复-优快云博客ORA-00600 [kdsgrp1-qetlbr] 块级损坏修复后的延续篇。环境还是Oracle 19c 19.24，此前该实例因存储双控制器主控同时物理故障，将数据卷整体迁移至新存储阵列。迁移完成后，数据库实例恢复正常，但后台进程持续报出新的内部错误。
故障现象
后台维护进程 M000（AWR 自动清理 slave）在执行 DELETE FROM WRM$_SNAPSHOT_DETAILS 时触发 ORA-00600 [13011]。这是 Oracle 自动工作负载仓库（AWR）的定期快照清理任务，属于后台静默维护操作。
错误堆栈进一步引发了 ORA-00447: fatal error in background process，后台进程异常退出后触发了实例级别的错误屏障（error barrier），属于高优先级故障。
2、错误现象：Alert 日志与 trace 文件
查看 alert 日志，发现 M000 进程密集报错：
alert_cdrcdb.log —
2025-12-10T00:08:30.802831+08:00
Dumping diagnostic data in directory=[cdmp_20251210000830],
requested by (instance=1, osid=97730 (M000)), summary=[incident=360978].
Errors in file /u01/app/oracle/diag/rdbms/cdrcdb/cdrcdb/trace/cdrcdb_m000_97730.trc
(incident=360979) (PDBNAME=CDB$ROOT):
ORA-00600: internal error code, arguments: [13011], [12199], [12727856], [91], [12753141], [0], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/cdrcdb/cdrcdb/incident/incdir_360979/cdrcdb_m000_97730_i360979.trc
2025-12-10T00:08:32.513500+08:00
Use ADRCI or Support Workbench to package the incident.
*** KEWRAPS: Error=600 encountered by Auto Purge slave.
ORA-00447: fatal error in background process打开 trace 文件，可以看到触发错误的具体 SQL 语句：
cdrcdb_m000_97730.trc — SQL 语句片段
ORA-00600: internal error code, arguments: [13011], [12199], [12727856], [91], [12753141], [0], ...
*** KEUUXS - encountered error: ORA-00600 [13011]
*** SQLSTR: total-len=144, dump-len=144,
SQLSTR={delete from WRM$_SNAPSHOT_DETAILS snap_det
where snap_det.dbid = :dbid
and snap_det.snap_id >= :beg_snap
and snap_det.snap_id <= :end_snap}
*** KEWRAPS: Error=600 encountered by Auto Purge slave.关键语句
错误发生在 AWR 自动清理 slave 执行删除 WRM$_SNAPSHOT_DETAILS 表数据时。这直接指向了 AWR 核心系统表的逻辑一致性问题。
3、错误参数解读
| 位置 | 值 | 含义 |
| Arg 1 | 13011 | 错误号：表与索引之间的逻辑不一致（Index/Table cross-reference failure） |
| Arg 2 | 12199 | 出问题对象的 Data Object ID（数据对象号） |
| Arg 3 | 12727856 | 第一个数据块的 RDBA（相对数据块地址） |
| Arg 4 | 91 | 行号 / 槽位信息 |
| Arg 5 | 12753141 | 第二个相关数据块的 RDBA |
| Arg 6 | 0 | 保留参数，通常为 0 |
ORA-00600 [13011] 的本质是：索引条目指向的 ROWID 在表数据块中找不到对应行或反过来表行在索引中缺失。这在存储迁移、异常掉电、Bug 场景下较为常见。
4、故障可能原因
存储物理故障导致块写入不完整
双控制器同时故障时，正在写入的数据块可能处于"半写"状态——表数据已更新但索引条目未同步更新，或反过来也一样。
AWR 清理任务放大了不一致性，清理任务发起时存储控制器hang住
WRM$_SNAPSHOT_DETAILS 是 AWR 快照明细表，数据量大且持续高频写入。自动清理任务执行 DELETE 时遍历索引，遇到不一致条目即触发 13011。
数据字典表损坏风险高
该表位于 SYSAUX 表空间，属于 SYS 用户数据字典。对其做 MOVE / REBUILD 需要格外谨慎，因为 AWR 功能依赖该表持续可用。
5、排查过程
5.1 通过 Data Object ID 定位对象
第一个有效手段是直接用 Arg2 的数据对象号查 DBA_OBJECTS：
SQLcl — 按 Data Object ID 查询
[oracle@cdb-104]:/u01/app/oracle/diag/rdbms/cdrcdb/cdrcdb/trace$ sql / as sysdba
SQLcl: Release 21.4 Production on Wed Dec 10 10:52:42 2025
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.24.0.0.0
SYS@CDB$ROOT> SELECT owner, object_name, object_type
2 FROM dba_objects
3 WHERE data_object_id = 12199;
OWNER OBJECT_NAME OBJECT_TYPE
__________ ________________________ ______________
SYS WRM$_SNAPSHOT_DETAILS TABLE
SYS@CDB$ROOT>5.2 RDBA 转换为文件号与块号
利用 DBMS_UTILITY 包将 Arg3 的 RDBA 值拆分为文件号和块号：
SQLcl — RDBA 转换
SYS@CDB$ROOT> SELECT DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE(12727856) AS "FILE#",
2 DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(12727856) AS "BLOCK#"
3 FROM DUAL;
FILE# BLOCK#
________ _________
3 144944
SYS@CDB$ROOT> SELECT owner, segment_name, segment_type, tablespace_name
2 FROM dba_extents
3 WHERE file_id = 3
4 AND 144944 BETWEEN block_id AND block_id + blocks - 1;
OWNER SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME
__________ ________________________ ______________ ________________
SYS WRM$_SNAPSHOT_DETAILS TABLE SYSAUX
SYS@CDB$ROOT> SELECT COUNT(*) FROM WRM$_SNAPSHOT_DETAILS;
COUNT(*)
___________
47708
SYS@CDB$ROOT>5.3 查看 trace 文件中的块转储
trace 文件中包含了完整的 buffer cache 块转储，可以看到行数据的物理结构：
cdrcdb_m000_97730.trc — 块转储片段
tab 0, row 131, @0x7a5
tl: 46 fb: --H-FL-- lb: 0x2 cc: 7
col 0: [ 3] c2 5c 3c
col 1: [ 6] c5 05 62 06 40 03
col 2: [ 2] c1 02
col 3: [ 2] c1 19
col 4: [11] 78 7d 09 14 0d 01 24 17 01 e4 80
col 5: [11] 78 7d 09 14 0d 01 24 17 01 e4 80
col 6: [ 1] 80
tab 0, row 132, @0x777
tl: 46 fb: --H-FL-- lb: 0x2 cc: 7
col 0: [ 3] c2 5c 3c
col 1: [ 6] c5 05 62 06 40 03
col 2: [ 2] c1 02
col 3: [ 2] c1 1a
col 4: [11] 78 7d 09 14 0d 01 24 17 01 e4 80
col 5: [11] 78 7d 09 14 0d 01 24 17 2f ab 40
col 6: [ 1] 80
... 共转储 100+ 行 ...
end_of_block_dump
Dump of buffer cache for pdb 1 tsn 1 rdba 0xc23630 at level 10 done.5.4 验证表与索引一致性
使用 ANALYZE 命令做交叉引用校验，如果存在不一致会报 ORA-01499：
SQLcl — ANALYZE 结构验证
SYS@CDB$ROOT> ANALYZE TABLE SYS.WRM$_SNAPSHOT_DETAILS VALIDATE STRUCTURE CASCADE;
-- 未报 ORA-01499，但错误仍在持续发生
-- 说明不一致程度较隐蔽，或仅在特定 DELETE 路径触发
SYS@CDB$ROOT> SELECT index_name, uniqueness, status
2 FROM dba_indexes
3 WHERE table_name = 'WRM$_SNAPSHOT_DETAILS'
4 AND owner = 'SYS';
INDEX_NAME UNIQUENESS STATUS
______________________________ _____________ _________
WRM$_SNAPSHOT_DETAILS_INDEX NONUNIQUE VALID
SYS@CDB$ROOT>修复困扰之处
ANALYZE 验证显示索引状态为 VALID，但 ORA-00600 [13011] 仍持续发生。这说明问题不是传统意义上的"索引损坏"，而是存储迁移后块级别的逻辑错位——索引条目和表行在物理位置上对应不上。
6、修复过程：MOVE 表 + 重建索引
6.1 移动表（重组物理存储）
直接对表执行 MOVE 操作，让 Oracle 重新组织数据段，彻底重建表的物理存储布局：
SQLcl — ALTER TABLE MOVE
SYS@CDB$ROOT> ALTER TABLE SYS.WRM$_SNAPSHOT_DETAILS MOVE;
Table altered.
-- MOVE 操作完成后，表的物理存储位置被重新组织
-- 注意：此操作会导致该表上所有索引失效（UNUSABLE）6.2 检查并重建失效索引
MOVE 之后必须检查索引状态并逐一重建：
SQLcl — 检查失效索引
SYS@CDB$ROOT> SELECT index_name, status
2 FROM dba_indexes
3 WHERE table_name = 'WRM$_SNAPSHOT_DETAILS'
4 AND owner = 'SYS';
INDEX_NAME STATUS
______________________________ ___________
WRM$_SNAPSHOT_DETAILS_INDEX UNUSABLE
-- Alert 日志同时记录：
-- 2025-12-11T08:58:32.085677+08:00
-- Some indexes or index [sub]partitions of table
-- SYS.WRM$_SNAPSHOT_DETAILS have been marked unusable
SYS@CDB$ROOT> ALTER INDEX SYS.WRM$_SNAPSHOT_DETAILS_INDEX REBUILD ONLINE;
Index altered.
SYS@CDB$ROOT> SELECT index_name, status
2 FROM dba_indexes
3 WHERE table_name = 'WRM$_SNAPSHOT_DETAILS'
4 AND owner = 'SYS';
INDEX_NAME STATUS
______________________________ _________
WRM$_SNAPSHOT_DETAILS_INDEX VALID
SYS@CDB$ROOT>6.3 清理过期 AWR 快照
WRM$_SNAPSHOT_DETAILS 是 AWR 快照明细表。Oracle 11.2.0.3 之后存在已知 Bug（如 Bug 14084247），导致快照无法按保留策略自动清理。手动清理过期快照：
SQLcl — 手动清理 AWR 快照
SYS@CDB$ROOT> BEGIN
2 DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(
3 low_snap_id => 1, -- 起始快照ID
4 high_snap_id => 10000, -- 结束快照ID
5 dbid => XXXX); -- 记得使用使用当前DBID
6 END;
7 /
PL/SQL procedure successfully completed.
-- 注意：此操作不可逆，执行前务必、务必，请确认快照范围6.4 手动创建快照验证 AWR 功能
修复后手动触发一次快照采集，确认 AWR 功能恢复正常：
SQLcl — 验证 AWR 功能
SYS@CDB$ROOT> EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();
PL/SQL procedure successfully completed.
SYS@CDB$ROOT> ANALYZE TABLE SYS.WRM$_SNAPSHOT_DETAILS VALIDATE STRUCTURE CASCADE;
Table analyzed.
-- 验证通过，表与索引一致性恢复7、 使用原生ADRCI show问题
用 ADRCI 命令行工具查看所有已知问题和事件，确认本次故障的完整影响范围：
ADRCI — 问题汇总
[oracle@cdb-104]$ adrci
ADR Home = /u01/app/oracle/diag/rdbms/cdrcdb/cdrcdb:
*************************************************************************
adrci> show problem
PROBLEM_ID PROBLEM_KEY LAST_INCIDENT LASTINC_TIME
____________ ___________________________________ ________________ __________________________
3 ORA 600 [ORA-00600 ... [13011] 361401 2025-08-29 00:05:45.772
4 ORA 600 [13011] 360978 2025-12-10 00:08:28.758
38 ORA 600 [ORA-00600 ... [13011] 360979 2025-12-10 00:08:30.828
37 rows fetched
adrci> show incident -all
INCIDENT_ID PROBLEM_KEY CREATE_TIME
______________ ____________________________________ __________________________
361112 ORA 600 [kdsgrp1-qetlbr] 2025-08-21 01:10:06.303
...
360978 ORA 600 [13011] 2025-12-10 00:08:28.758
360979 ORA 600 [ORA-00600 ... [13011] 2025-12-10 00:08:30.828
235 rows fetched
adrci> exitTIPS:
- MOVE 不会删除表：表名、所有者不变，只是物理存储位置被重新组织。
- 索引必然失效：执行 MOVE 后，该表上所有普通索引变为 UNUSABLE，必须手动重建。
- AWR 不会重建表：WRM$_SNAPSHOT_DETAILS 是数据字典基础表，MOVE 后 AWR 机制会继续使用它，不会自动创建新表。
- 注意 SYSAUX 空间：MOVE 需要约等于表大小的额外空间，请提前检查 SYSAUX 表空间余量。
- 对数据字典表操作需谨慎：SYS 用户的表是 Oracle 核心组件，操作前确认备份，避免在业务高峰期执行。
1925
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
