内容阅读

在知识库中专注阅读，并随时返回相关工具与课程

故障排查35 分钟阅读

ORA-00600 [25027] [x] [0] 问题分析思路与疑惑

大家好，这里是 Lucifer三思而后行，专注于提升数据库运维效率。 @TOC目录一大早还没上班，客户紧急告知应用频繁报错：ORA-00600 25027，且产线大面积无法使用，需要帮忙分析问题原因以及如何解决。参考 MOS 文档： - ORA-600 25027 Doc ID 284433.1https://support.oracle.com/epmos/faces/DocContentD

2024年9月10日

database

DBA 实战课程

系统学习 Oracle DBA

2738+ 篇实战文章
1500+ 步骤截图
10 大核心模块

开通会员 ¥128/月起

查看完整课程

返回博客列表

故障排查35 分钟阅读

ORA-00600 [25027] [x] [0] 问题分析思路与疑惑

2024年9月10日

database

大家好，这里是 Lucifer三思而后行，专注于提升数据库运维效率。

前言

本章目标：掌握本章核心知识点 前置要求：完成前序章节学习 预计时长：60 分钟

一大早还没上班，客户紧急告知应用频繁报错：ORA-00600 [25027]，且产线大面积无法使用，需要帮忙分析问题原因以及如何解决。

参考 MOS 文档：

以下仅为个人分析记录，仅供参考。

问题分析

已知当前报错的库为一套 3 节点 19.21 RAC 数据库。

日志分析

通过 adrci 查看最近是否有 ORA 报错：

Bash

1## 发现 ORA-600 报错
2PROBLEM_ID           PROBLEM_KEY                                                 LAST_INCIDENT        LASTINC_TIME
3-------------------- ----------------------------------------------------------- -------------------- -----------------------------
42                    ORA 600 [ORA-00600: 內部錯誤代碼, 引數: [25027], [8 314306               2024-09-09 07:56:38.018000 +08:00

经检查 alert 日志报错内容为 ORA-600 [25027], [8], [0]，并且问题指向 TESTDB：

Bash

1ORA-00600: 內部錯誤代碼, 引數: [ORA-00600: 內部錯誤代碼, 引數: [25027], [8], [0], [], [], [], [], [], [], [], [], []
2], [], [], [], [], [], [], [], [], [], [], []
3ORA-02063: 在 line 之前, 自 TESTDB

查看 trace 详细日志内容发现对应 SQL 为一条 INSERT 语句，并且是通过 DBLINK 连接到 TESTDB 执行数据插入：

Bash

1INSERT INTO CUS_LUCIFER_UPLOAD_BASE@TESTDB (xxxxxxxxxxx) VALUES (xxxxxxxxxxxxx)

查看 TESTDB 库的 alert 日志内容，同样报错 ORA-600 [25027], [8], [0]：

Bash

1ORA-00600: 內部錯誤代碼, 引數: [25027], [8], [0], [], [], [], [], [], [], [], [], []

看来问题应该是出在 TESTDB 上，这是一套 11GR2（201020）补丁的单机数据库。

ORA-600 解析

ORA-600 是 Oracle 中非常常见的一种错误，大概率是由于 BUG 导致，所以需要查看一下 MOS 中对 ORA-600 [25027] (Doc ID 284433.1) 错误的介绍：

Bash

1ERROR:
2  Format: ORA-600 [25027] [a] [b]
3
4VERSIONS:
5  versions 9.2 and above
6
7ARGUMENTS:
8  Arg [a]  Tablespace Number (TSN)
9  Arg [b]  Decimal Relative Data Block Address (RDBA)
10
11In 12c it includes Multitenant information:
12  
13  Arg [a]  0 if Multitenant is not enabled or 0 if there is not Root CDB session, 1 ROOT PDBID, otherwise PDBID top session
14  Arg [b]  PDBID
15  Arg [c]  Tablespace Number (TSN)
16  Arg [d]  Decimal Relative Data Block Address (RDBA)

因为 TESTDB 是一套 11GR2 的库，所以只需要看对应版本的 ARGUMENTS 即可：

Bash

1ARGUMENTS:
2  Arg [a]  Tablespace Number (TSN)
3  Arg [b]  Decimal Relative Data Block Address (RDBA)

通过 alert 报错信息可以发现 [a] [b] 对应的值为 [8] [0]，a 代表的是表空间的号，b 代表的是 RDBA（数据块的十进制地址）。

MOS 针对报错给出的分析建议如下：

Bash

1SUGGESTIONS:
2  
3 1. If the Arg [b] or [d] in 12c (the RDBA) is 0 (zero), then this could be caused by fake indexes.  The following query will list fake indexes:
4
5     select do.owner,do.object_name, do.object_type,sysind.flags
6     from dba_objects do, sys.ind$ sysind
7     where do.object_id = sysind.obj#
8     and bitand(sysind.flags,4096)=4096;
9
10  If the above query returns any rows, check the objects involved and consider dropping them as they can cause this error. 
11
12  or it could be the case described in the next article when allocating a block for a LOB segment in a DML:
13     Note 1608861.1 ORA-00600 [25027] [x] [0] 
14
152. Run analyze table validate structure on the table referenced in the Current SQL statement in 
16    the related trace file.
17
18  If the Known Issues section below does not help in terms of identifying
19  a solution, please submit the trace files and alert.log to Oracle 
20  Support Services for further analysis.

这里第一条的 b 值为 0，看起来与我们的情况有些相符，大概意思有可能是由虚假索引导致的，建议检查是否存在虚假索引：

SQL

1SQL> select do.owner,do.object_name, do.object_type,sysind.flags
2     from dba_objects do, sys.ind$ sysind
3     where do.object_id = sysind.obj#
4     and bitand(sysind.flags,4096)=4096;
5
6no rows selected

很不幸，没有查到任何内容，看来不符合这个建议。下面说有可能是对 LOB 对象做 DML 操作时导致，初看也与我们的情况比较相似，因为报错 SQL 确实是一个 INSERT 操作，所以需要确认以下表是否有 LOB 字段：

SQL

1SQL> desc LUCIFER.CUS_LUCIFER_UPLOAD_BASE
2 Name                                      Null?    Type
3 ----------------------------------------- -------- ----------------------------
4 UPDATE_TIME                                        DATE
5 TERMINAL_ID                                        NUMBER
6 PART_ID                                            NUMBER
7 RESULT                                             VARCHAR2(32)
8 SUM_COUNT                                          NUMBER
9 SUCC_COUNT                                         NUMBER
10 FAIL_COUNT                                         NUMBER
11 WORK_ORDER                                         VARCHAR2(32)
12 UPLOAD_TIME                                        DATE
13 KEYID                                              VARCHAR2(64)
14 FTP_PATH                                           VARCHAR2(1024)
15 FTP_TYPE                                           NUMBER
16 UPDATE_EMPNO                                       VARCHAR2(64)
17 MACHINE_ID                                         NUMBER
18 RECID                                              VARCHAR2(256)
19 CREATE_TIME                                        DATE
20 CREATE_DATE                                        NUMBER

检查后发现没有 LOB 字段，还是不符合。那就只能看第二种建议了，建议对表进行 analyze validate structure 操作，看来是怀疑有坏块，也有一定的可能性：

SQL

1-- 首先确保当前数据库中没有坏块
2SQL> select * from V$DATABASE_BLOCK_CORRUPTION;
3
4no rows selected
5
6-- analyze 表
7SQL> set timing on
8SQL> analyze table CUS_LUCIFER_UPLOAD_BASE validate structure;
9
10Table analyzed.
11
12Elapsed: 00:01:22.63
13
14-- analyze 表和索引
15SQL> analyze table CUS_LUCIFER_UPLOAD_BASE validate structure cascade;
16
17Table analyzed.
18
19Elapsed: 01:14:04.09

看来表和索引都没有任何问题，不存在逻辑坏块。那么有没有可能存在物理坏块，查看表和索引所在的数据文件：

SQL

1-- 查看 a 值 8 对应的表空间数据文件，对应的都是索引表空间
2SQL> select t.ts#, t.name tablespace_name, f.file#, f.name file_name
3from v$tablespace t, v$datafile f
4where t.ts#=f.ts# and t.ts#=8;
5
6TS# TABLESPACE_NAME FILE# FILE_NAME
7---------- ------------------------------ ---------- ----------------------------------------------------------------------------------------------------
88 luciferidx 6 /oradata/testdb/luciferidx01.dbf
98 luciferidx 7 /oradata/testdb/luciferidx02.dbf
108 luciferidx 8 /oradata/testdb/luciferidx03.dbf
118 luciferidx 333 /oradata2/testdb/dataidx231120.dbf
128 luciferidx 365 /oradata2/testdb/dataidx240412.dbf
13
14-- 查看表所在的数据文件
15select file_name from dba_tables t1, dba_data_files t2
16　　where t1.tablespace_name=t2.tablespace_name
17　　and t1.owner='LUCIFER' and t1.table_name='CUS_LUCIFER_UPLOAD_BASE';
18
19FILE_NAME
20----------------------------------------------------------------------------------------------------
21/oradata2/testdb/lucifer04.dbf
22/oradata/testdb/lucifer03.dbf
23/oradata/testdb/lucifer02.dbf
24/oradata/testdb/lucifer01.dbf

对表和索引所在的数据文件进行 dbv 分析：

Bash

1dbv file=/oradata/testdb/luciferidx01.dbf blocksize=8192
2dbv file=/oradata/testdb/luciferidx02.dbf blocksize=8192
3dbv file=/oradata/testdb/luciferidx03.dbf blocksize=8192
4dbv file=/oradata2/testdb/dataidx231120.dbf blocksize=8192
5dbv file=/oradata2/testdb/dataidx240412.dbf blocksize=8192

rman check 分析：

Bash

1RMAN> backup check logical validate datafile '/oradata/testdb/lucifer01.dbf';
2RMAN> backup check logical validate datafile '/oradata/testdb/lucifer02.dbf';
3RMAN> backup check logical validate datafile '/oradata/testdb/lucifer03.dbf';
4RMAN> backup check logical validate datafile '/oradata2/testdb/lucifer04.dbf';

查看坏块：

SQL

1SQL> select * from V$DATABASE_BLOCK_CORRUPTION;
2
3no rows selected

没有发现任何坏块，看来坏块的怀疑也排除了。

这里抱着重启试试的心态，把 TESTDB 数据库重启了一下，发现依然频繁报错，没有任何改善。

DBLINK 问题？

开发怀疑有可能是 DBLINK 导致的问题，所以重建了 DBLINK，不幸的是，重建后依然报错。后面索性直接不使用 DBLINK，改为在本地建一张表，然后直接在本地插入数据，确实可行，数据库没有再报错，产线也恢复正常。

到这里，看起来可能是使用 DBLINK 导致的问题，所以查了 2pc 分布式事务的相关情况，没有发现异常，所以还是怀疑是 TESTDB 的这张表有问题，那就重建这张表试试。

解决方案

经过跟开发沟通之后，在 TESTDB 重建表，把原表 RENAME 重建之后，恢复 DBLINK，持续观察了一段时间，发现产线恢复正常，ORA-600 报错消失：

SQL

1alter table  LUCIFER.CUS_LUCIFER_UPLOAD_BASE rename to CUS_LUCIFER_UPLOAD_BASE_BAK;
2create table LUCIFER.CUS_LUCIFER_UPLOAD_BASE tablespace lucifer as select * from LUCIFER.CUS_LUCIFER_UPLOAD_BASE_BAK;
3create index LUCIFER.IDX_LUCIFER_ATEUPLOAD_BASE_SN on CUS_LUCIFER_UPLOAD_BASE (TERMINAL_ID) tablespace LUCIFERIDX parallel 32;
4alter index  LUCIFER.IDX_LUCIFER_ATEUPLOAD_BASE_SN noparallel;

问题虽然解决了，但是我一脸懵逼，看起来就是这张表出问题了，但是问题到底出在哪里了？

后记

开了 Oracle Case，得到回复如下：

Bash

1这次的现象属于 Logical Block Corruptions(逻辑破损)的范畴。
2
3Ref:
4Physical and Logical Block Corruptions. All you wanted to know about it. ( Doc ID 840978.1 )
5
6Logical Block Corruptions
7
8This is when block contains a valid checksum and the structure below the beginning of the block is corrupt (Block content is corrupt). It may cause different ORA-600 errors.
9The detailed corruption description for Logical Corruptions are not normally printed in the alert.log. DBVerify will report what is logically corrupted in the block.
10
11事后想追溯其根本原因说实话其实是非常困难的。因为涉及到的层面比较多，比如存储，OS I/O 写，应用(Oracle)等层面都有可能引起 逻辑破损 的可能性。
12
13Ref:
14Handling Oracle Block Corruptions ( Doc ID 28814.1 )
15
16Overview of Steps to handle a Corruption
17
18There are many possible causes of a block corruption including:
19・Bad IO hardware / firmware
20・OS problems
21・Oracle problems
22・Recovering through "UNRECOVERABLE" or "NOLOGGING" database actions
23　(in which case ORA-1578 is expected behaviour - see below)
24
25比如，已知的和存储相关的现象，烦请参考下面的技术文档。
26
27Ref:
28Database Corruption due to stale/old blocks after EMC SRDF/A DR switchover - ORA-600 [25027] ORA-600 [kdsgrp1] ORA-8103 ORA-1410 ( Doc ID 1675764.1 )

以上仅供参考。

往期精彩文章推荐

Oracle 数据库启动过程之 nomount 详解 Oracle RAC 修改系统时区避坑指南（深挖篇） Ubuntu 22.04 一键安装 Oracle 11G RAC 使用 dbops 快速部署 MySQL 数据库 Oracle RAC 启动顺序，你真的了解吗？达梦数据库一键安装脚本（免费）一篇文章让你彻底掌握 Python 🔥
一篇文章让你彻底掌握 Python 一篇文章让你彻底掌握 Shell 🔥
Oracle 监控 EMCC 13.5 安装部署超详细教程 🔥
Oracle 一键巡检自动生成 Word 报告 🔥
Oracle一键安装脚本的 21 个疑问与解答 🔥
Oracle一键巡检脚本的 21 个疑问与解答 🔥
全网首发：Oracle 23ai 一键安装脚本 🔥
Oracle 19C 最新 RU 补丁 19.24 ，一键安装！ 🔥
Oracle Linux 6 一键安装 Oracle 11GR2 RAC
Oracle Linux 7.9 一键安装 Oracle 19C
Oracle Linux 8.9 一键安装 Oracle 19C RAC
Oracle Linux 9.4(aarch64) 一键安装 Oracle 19C 🔥
openEuler 20.03 LTS SP4 一键安装 Oracle 19C 🔥
openEuler 22.03 LTS SP4 一键安装 Oracle 19C RAC
RHEL 7.9 一键安装 Oracle 19C 19.23 RAC
Redhat 8.4 一键安装 Oracle 11GR2
RedHat 9.4(aarch64) 一键安装 Oracle 19C
龙蜥 Anolis 7.9 一键安装 Oracle 19C 19.23
龙蜥 Anolis OS 8.8 一键安装 Oracle 19C
SUSE 15 SP5 一键安装 Oracle 19C
统信 UOS V20 1070(a) 一键安装 Oracle 11GR2
Ubuntu 22.04 一键安装 Oracle 19C
Ubuntu 14.04 一键安装 Oracle 19C
银河麒麟 Kylin V10 SP3 一键安装 Oracle 19C 🔥
银河麒麟 Kylin V10 SP3 一键安装 Oracle 11GR2 RAC
Oracle DataGuard GAP 修复手册 🔥
优化 Oracle：最佳实践与开发规范
 DBA 必备：Linux 软件源配置全攻略 🔥
Linux 一键配置时钟同步全攻略 🔥
Starwind 配置 ISCSI 共享存储
 SUSE 15 SP3 安装 Oracle 19C RAC 数据库
 达梦 8 数据库安装手册 🔥
Oracle 12CR2 RAC 安装避坑宝典
 Linux7 安装 Oracle 19C RAC 详细图文教程 🔥
Oracle ADG 搭建 RAC to Single 详细教程
 Oracle DataGuard GAP 修复手册 🔥
Oracle 分区表之在线重定义
 AutoUpgrade 快速升级 Oracle 数据库
 Oracle 数据库巡检命令手册 🔥
Oracle 数据坏块的 N 种修复方式 🔥
数据库 SQL 开发入门教程
 超全 Linux 基础命令总结 🔥
VMware 虚拟机安装 Linux 系统
 Linux 安装 MySQL 详细教程
 教你玩转 SQLPLUS，工作效率提升 200%

感谢您的阅读，这里是 Lucifer三思而后行，欢迎 点赞+关注，我会持续分享数据库知识、运维技巧。

DBA 实战课程

系统学习 Oracle DBA

2738+ 篇实战文章
1500+ 步骤截图
10 大核心模块

开通会员 ¥128/月起

查看完整课程

大家好，这里是 Lucifer三思而后行，专注于提升数据库运维效率。

前言

本章目标：掌握本章核心知识点 前置要求：完成前序章节学习 预计时长：60 分钟

一大早还没上班，客户紧急告知应用频繁报错：ORA-00600 [25027]，且产线大面积无法使用，需要帮忙分析问题原因以及如何解决。

参考 MOS 文档：

以下仅为个人分析记录，仅供参考。

问题分析

已知当前报错的库为一套 3 节点 19.21 RAC 数据库。

日志分析

通过 adrci 查看最近是否有 ORA 报错：

Bash

1## 发现 ORA-600 报错
2PROBLEM_ID           PROBLEM_KEY                                                 LAST_INCIDENT        LASTINC_TIME
3-------------------- ----------------------------------------------------------- -------------------- -----------------------------
42                    ORA 600 [ORA-00600: 內部錯誤代碼, 引數: [25027], [8 314306               2024-09-09 07:56:38.018000 +08:00

经检查 alert 日志报错内容为 ORA-600 [25027], [8], [0]，并且问题指向 TESTDB：

Bash

1ORA-00600: 內部錯誤代碼, 引數: [ORA-00600: 內部錯誤代碼, 引數: [25027], [8], [0], [], [], [], [], [], [], [], [], []
2], [], [], [], [], [], [], [], [], [], [], []
3ORA-02063: 在 line 之前, 自 TESTDB

查看 trace 详细日志内容发现对应 SQL 为一条 INSERT 语句，并且是通过 DBLINK 连接到 TESTDB 执行数据插入：

Bash

1INSERT INTO CUS_LUCIFER_UPLOAD_BASE@TESTDB (xxxxxxxxxxx) VALUES (xxxxxxxxxxxxx)

查看 TESTDB 库的 alert 日志内容，同样报错 ORA-600 [25027], [8], [0]：

Bash

1ORA-00600: 內部錯誤代碼, 引數: [25027], [8], [0], [], [], [], [], [], [], [], [], []

看来问题应该是出在 TESTDB 上，这是一套 11GR2（201020）补丁的单机数据库。

ORA-600 解析

ORA-600 是 Oracle 中非常常见的一种错误，大概率是由于 BUG 导致，所以需要查看一下 MOS 中对 ORA-600 [25027] (Doc ID 284433.1) 错误的介绍：

Bash

1ERROR:
2  Format: ORA-600 [25027] [a] [b]
3
4VERSIONS:
5  versions 9.2 and above
6
7ARGUMENTS:
8  Arg [a]  Tablespace Number (TSN)
9  Arg [b]  Decimal Relative Data Block Address (RDBA)
10
11In 12c it includes Multitenant information:
12  
13  Arg [a]  0 if Multitenant is not enabled or 0 if there is not Root CDB session, 1 ROOT PDBID, otherwise PDBID top session
14  Arg [b]  PDBID
15  Arg [c]  Tablespace Number (TSN)
16  Arg [d]  Decimal Relative Data Block Address (RDBA)

因为 TESTDB 是一套 11GR2 的库，所以只需要看对应版本的 ARGUMENTS 即可：

Bash

1ARGUMENTS:
2  Arg [a]  Tablespace Number (TSN)
3  Arg [b]  Decimal Relative Data Block Address (RDBA)

通过 alert 报错信息可以发现 [a] [b] 对应的值为 [8] [0]，a 代表的是表空间的号，b 代表的是 RDBA（数据块的十进制地址）。

MOS 针对报错给出的分析建议如下：

Bash

1SUGGESTIONS:
2  
3 1. If the Arg [b] or [d] in 12c (the RDBA) is 0 (zero), then this could be caused by fake indexes.  The following query will list fake indexes:
4
5     select do.owner,do.object_name, do.object_type,sysind.flags
6     from dba_objects do, sys.ind$ sysind
7     where do.object_id = sysind.obj#
8     and bitand(sysind.flags,4096)=4096;
9
10  If the above query returns any rows, check the objects involved and consider dropping them as they can cause this error. 
11
12  or it could be the case described in the next article when allocating a block for a LOB segment in a DML:
13     Note 1608861.1 ORA-00600 [25027] [x] [0] 
14
152. Run analyze table validate structure on the table referenced in the Current SQL statement in 
16    the related trace file.
17
18  If the Known Issues section below does not help in terms of identifying
19  a solution, please submit the trace files and alert.log to Oracle 
20  Support Services for further analysis.

这里第一条的 b 值为 0，看起来与我们的情况有些相符，大概意思有可能是由虚假索引导致的，建议检查是否存在虚假索引：

SQL

1SQL> select do.owner,do.object_name, do.object_type,sysind.flags
2     from dba_objects do, sys.ind$ sysind
3     where do.object_id = sysind.obj#
4     and bitand(sysind.flags,4096)=4096;
5
6no rows selected

SQL

1SQL> desc LUCIFER.CUS_LUCIFER_UPLOAD_BASE
2 Name                                      Null?    Type
3 ----------------------------------------- -------- ----------------------------
4 UPDATE_TIME                                        DATE
5 TERMINAL_ID                                        NUMBER
6 PART_ID                                            NUMBER
7 RESULT                                             VARCHAR2(32)
8 SUM_COUNT                                          NUMBER
9 SUCC_COUNT                                         NUMBER
10 FAIL_COUNT                                         NUMBER
11 WORK_ORDER                                         VARCHAR2(32)
12 UPLOAD_TIME                                        DATE
13 KEYID                                              VARCHAR2(64)
14 FTP_PATH                                           VARCHAR2(1024)
15 FTP_TYPE                                           NUMBER
16 UPDATE_EMPNO                                       VARCHAR2(64)
17 MACHINE_ID                                         NUMBER
18 RECID                                              VARCHAR2(256)
19 CREATE_TIME                                        DATE
20 CREATE_DATE                                        NUMBER

检查后发现没有 LOB 字段，还是不符合。那就只能看第二种建议了，建议对表进行 analyze validate structure 操作，看来是怀疑有坏块，也有一定的可能性：

SQL

1-- 首先确保当前数据库中没有坏块
2SQL> select * from V$DATABASE_BLOCK_CORRUPTION;
3
4no rows selected
5
6-- analyze 表
7SQL> set timing on
8SQL> analyze table CUS_LUCIFER_UPLOAD_BASE validate structure;
9
10Table analyzed.
11
12Elapsed: 00:01:22.63
13
14-- analyze 表和索引
15SQL> analyze table CUS_LUCIFER_UPLOAD_BASE validate structure cascade;
16
17Table analyzed.
18
19Elapsed: 01:14:04.09

看来表和索引都没有任何问题，不存在逻辑坏块。那么有没有可能存在物理坏块，查看表和索引所在的数据文件：

SQL

1-- 查看 a 值 8 对应的表空间数据文件，对应的都是索引表空间
2SQL> select t.ts#, t.name tablespace_name, f.file#, f.name file_name
3from v$tablespace t, v$datafile f
4where t.ts#=f.ts# and t.ts#=8;
5
6TS# TABLESPACE_NAME FILE# FILE_NAME
7---------- ------------------------------ ---------- ----------------------------------------------------------------------------------------------------
88 luciferidx 6 /oradata/testdb/luciferidx01.dbf
98 luciferidx 7 /oradata/testdb/luciferidx02.dbf
108 luciferidx 8 /oradata/testdb/luciferidx03.dbf
118 luciferidx 333 /oradata2/testdb/dataidx231120.dbf
128 luciferidx 365 /oradata2/testdb/dataidx240412.dbf
13
14-- 查看表所在的数据文件
15select file_name from dba_tables t1, dba_data_files t2
16　　where t1.tablespace_name=t2.tablespace_name
17　　and t1.owner='LUCIFER' and t1.table_name='CUS_LUCIFER_UPLOAD_BASE';
18
19FILE_NAME
20----------------------------------------------------------------------------------------------------
21/oradata2/testdb/lucifer04.dbf
22/oradata/testdb/lucifer03.dbf
23/oradata/testdb/lucifer02.dbf
24/oradata/testdb/lucifer01.dbf

对表和索引所在的数据文件进行 dbv 分析：

Bash

1dbv file=/oradata/testdb/luciferidx01.dbf blocksize=8192
2dbv file=/oradata/testdb/luciferidx02.dbf blocksize=8192
3dbv file=/oradata/testdb/luciferidx03.dbf blocksize=8192
4dbv file=/oradata2/testdb/dataidx231120.dbf blocksize=8192
5dbv file=/oradata2/testdb/dataidx240412.dbf blocksize=8192

rman check 分析：

Bash

1RMAN> backup check logical validate datafile '/oradata/testdb/lucifer01.dbf';
2RMAN> backup check logical validate datafile '/oradata/testdb/lucifer02.dbf';
3RMAN> backup check logical validate datafile '/oradata/testdb/lucifer03.dbf';
4RMAN> backup check logical validate datafile '/oradata2/testdb/lucifer04.dbf';

查看坏块：

SQL

1SQL> select * from V$DATABASE_BLOCK_CORRUPTION;
2
3no rows selected

没有发现任何坏块，看来坏块的怀疑也排除了。

这里抱着重启试试的心态，把 TESTDB 数据库重启了一下，发现依然频繁报错，没有任何改善。

ORA-00600 [25027] [x] [0] 问题分析思路与疑惑 - DBA 学习之路