ora 06512是什么错误_存储故障导致RAC数据库 ORA600[kclchkblk_4]错误故障修复图文版...

大家好，我是黄伟老师。前几天，一位网友的数据库因为双存储控制器故障，导致一套跑在该存储上的Oracle11gR2 RAC数据库异常，出现ORA-600的错误，数据库无法正常启动，影响业务系统的正常使用和生产，于是找我帮忙处理。处理完这个case之后，现在我把当时的情景尽可能的还原出来，录制成这个视频，希望各位观看学习之后，将来如果在你的工作中，也出现类似的数据库故障，可以起到一个参考指导的作用，提供一个分析的思路，帮各位快速定位和恢复启动数据库。当然，这里面会涉及到一些Oracle数据库的运行原理和一些专业术语，比如SCN、Checkpoint，不过我会尽可能尝试着把它们讲清楚。

一 首先，接到帮助请求

二 分析错误和定位问题

对于不熟悉Oracle错误的同学，可以参考metalink(Oracle官方技术支持网站)官方文档(What is an ORA-600 Internal Error? (Doc ID 146580.1))的解释：

什么是ORA-600？

*ORA-600 errors are raised from thekernel codeof the Oracle RDBMS software when aninternal inconsistencyis detected or an unexpected condition is met. This situation isnot necessarily a bugas it might be caused by problems with the Operating System, lack of resources, hardware failures, etc.

With the ORA-600 error comes a list of arguments insquare brackets.The first of these arguments tells us from where in the code the error was caught and thus is the key information in identifying the problem. This argument is either a number or a character string. The remaining arguments are used to supply further information (e.g. values of internal variables etc).

Whenever an ORA-600 error is raised a trace file is generated and an entry written to the alert.log with details of the trace file location. Starting with Oracle Database 11g Release 1, the diagnosability infrastructure was introduced which places the trace and core files into a location controlled by the DIAGNOSTIC_DEST initialization parameter when an incident, such as an ORA-600 is created. For earlier versions, the trace file will be written to either USER_DUMP_DEST (if the error was caught in a user process) or BACKGROUND_DUMP_DEST (if the error was caught in a background process like PMON or SMON). The trace file contains vital information about what led to the error condition.*

所以，我们从错误信息参数中，可以猜测出，ORA-00600: internal error code, arguments: [kclchkblk_4]应该是跟数据块错误有关的可能性很大。再结合这个案例，网友提供的信息说存储控制器故障，猜测多半情况下，数据库在运行(数据库进程通过内存空间，频繁和存储设备读写数据)的过程中，存储控制器一旦故障，多数情况下会导致内存中的脏数据(被修改过的数据)无法写入数据库，或者数据库检查点信息无法同步到控制文件、日志文件、数据文件中。那么数据库必死无疑，无法再继续工作下去了，当我们下次手工启库、或者数据库自动重启的过程中，数据库在open阶段，如果数据库无法完成一致性校验或者Instance Recovery实例恢复，那么数据库就无法Open，不能对业务系统提供服务了。

那么，本案例中，这个ORA-00600: internal error code, arguments: [kclchkblk_4]究竟表示什么意思呢？后面的几个参数又表示什么呢？我想，如果我们能把这几个参数搞清楚的话，那么这个问题也许就有眉目了。

于是，从metalink上找到跟该错误有关的几篇文章：

1 ORA-600 [kclchkblk_4] (Doc ID 1522401.1)

从ORA-600 [kclchkblk_4] (Doc ID 1522401.1)这篇文档中，获取的信息有限，只是说：目前该错误并没有完全公开发布出来，因为它通常伴随ORA-600错误出现，而且被认为是已知确认的bug。

2 Bug 14351566 – ORA-600 [kclchkblk_4] ORA-600 [2662] when doing flash back (Doc ID 14351566.8)

该文档描述的是数据库多次执行flashback之后，导致的bug。我们该故障场景中，数据库并没有执行flashback的操作，排除。

3 ORA-600 [2662] “Block SCN is ahead of Current SCN” (Doc ID 28929.1)

不过，从该指导文档中可以获取到对此案例有用的指导信息。

① 该错误比较常见，通常由于存储故障、或者服务器异常掉电，数据库abort关闭等，导致的数据块里记录的SCN与数据库当前SCN不一致导致的。解决问题的常规办法就是通过redo log恢复数据，如果依然不奏效的话，可能需要通过非常规手段来修改数据库的SCN，使之一致，进而避免该错误发生。

这里，我在一套测试环境上模拟了该错误，并且手工修复了该错误：

这里，我在一套测试环境上模拟了该错误，并且手工修复了该错误：

Sat Dec 19 08:55:28 2020SMON: enabling cache recoveryErrors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_8251.trc  (incident=28953):ORA-00600: internal error code, arguments: [2662], [0], [112587826], [0], [112587881], [4194432], [], [], [], [], [], []Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_28953/orcl_ora_8251_i28953.trcErrors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_8251.trc:ORA-00600: inter