ORA-00600: internal error code, arguments: [kdBlkCheckError]

1. 现象
2. 分析
3. 故障处理

1 现象

在数据库宕机前出现ORA-00600错误。日志内容如下：

ORA-01595: error freeing extent (4) of rollback segment (31))

ORA-00607: Internal error occurred while making a change to a data block

ORA-00600: internal error code, arguments: [kdBlkCheckError], [3], [3], [18018], [], [], [], [], [], [], [], []

Corrupt Block Found

         TSN = 2, TSNAME = UNDOTBS1

         RFN = 3, BLK = 3, RDBA = 12582915

         OBJN = 2, OBJD = -1, OBJECT = , SUBOBJECT =

         SEGMENT OWNER = , SEGMENT TYPE =

Wed Aug 02 10:00:05 2017

Dumping diagnostic data in directory=[cdmp_20170802100005], requested by (instance=1, osid=24055 (SMON)), summary=[incident=48868].

Errors in file /oracle/app/oracle/diag/rdbms/aiboss/aiboss/trace/aiboss_smon_24055.trc  (incident=61108):

ORA-00600: internal error code, arguments: [kdBlkCheckError], [3], [3], [18018], [], [], [], [], [], [], [], []

Incident details in: /oracle/app/oracle/diag/rdbms/aiboss/aiboss/incident/incdir_61108/aiboss_smon_24055_i61108.trc

Wed Aug 02 10:00:11 2017

PMON (ospid: 24025): terminating the instance due to error 474

System state dump requested by (instance=1, osid=24025 (PMON)), summary=[abnormal instance termination].

System State dumped to trace file /oracle/app/oracle/diag/rdbms/aiboss/aiboss/trace/aiboss_diag_24035.trc

Instance terminated by PMON, pid = 24025

Wed Aug 02 10:40:19 2017

2 分析

错误分析 ORA-01595,ORA-00607,ORA-00600错误出现后，10:00:05秒Oracle开启记录此错误的相关信息,随后 Oracle PMON进行由SMON于无法清理资源，无法保证数据一致性而停止实例。 ORA-01595错误提的是数据库smon 进行清理回滚段的extent. 说明undo表空间出现问题。
BUG 确认

从宕机前的日志记录来看，数据库遇到的是oracle BUG 12349316. 依据为：

freeing extent (4) of rollback segment (31))                         =====> 与oracle BUG 12349316引发的条件一致，都是在清理extent时引发BUG.

[kdBlkCheckError], [ 3], [ 3], [ 18018]                              =====> 与oracle BUG 12349316 中600错误返回参数一致，都带有18018.

trace 日志(aiboss_smon_24055_i61108.trc)中发现 delete extent 函数    =====> FRAME [ 32] (ktusp_delextent()+76 -> ktsxr_delete())

3 故障处理

主要的处理思路是先跳过有问题的undo段，然后重建undo表空间

修改参数文件 数据库启动时，查找参数文件的顺序是spfile<ORACLE_SID>.ora –> init<ORACLE_SID>.ora –> init.ora. 因此Oracle 数据库倾向于使用spfile启动数据库。一般环境中也都使用spfile. 如何确认数据库使用的是spfile 还是pfile,使用 " show parameter spfile " 命令即可查看。

当数据库使用的是spfile参数文件时，由于spfile是二进制文件，我们不便于直接修改，因此需要先创建出一个pfile 文本文件。

create pfile='/tmp/pfile.ora' from spfile;

此命令的执行不需要启动数据库,进入sqlplus环境即可。

 在参数文件中加入以下内容：

undo_management = MANUAL             # UNDO 段管理方式改为manual

# 其他可添加内容：

*.fast_start_parallel_rollback=high  # 以4*cpu 个数开启回滚进程，但是实际上不会真的开始这么多。

*._allow_resetlogs_corruption = true # 如果数据库需要恢复，且undo与redo不一致，部分redo 无法恢复时需要此参数，允许resetlogs

启动数据库

startup mount pfile='/tmp/pfile.ora';

alter database open;

如果数据库需要recovery,则执行以下命令:

recover database until cancel;

alter database open resetlogs;

offline存在活动事务的的undo块

select segment_name,status,tablespace_name

from dba_rollback_segs

where status not in ('ONLINE', 'OFFLINE') ;

SEGMENT_NAME                   STATUS           TABLESPACE_NAME

------------------------------ ---------------- ------------------------------

_SYSSMU3_4004931649$           NEEDS RECOVERY   UNDOTBS1

_SYSSMU4_1126976075$           NEEDS RECOVERY   UNDOTBS1

_SYSSMU5_4011504098$           NEEDS RECOVERY   UNDOTBS1

将以上内容添加至刚创建的/tmp/pfile.ora中:

_CORRUPTED_ROLLBACK_SEGMENTS = ('_SYSSMU3_4004931649$','_SYSSMU4_1126976075$','_SYSSMU5_4011504098$')

"_corrupted_rollback_segments" 作用是不使用这几个回滚段。

重启数据库
```
startup force pfile='/tmp/pfile.ora';
```

重新创建undo 表空间

alter tablespace undotbs1 offline ;

drop tablespace undotbs1 including contents and datafiles;

create undo tablespace undotbs1 datafile '/data0/aiboss/undotbs1.dbf' size 30G autoextend off;

alter system set undo_tablespace='UNDOTBS1';

重启数据库 重启数据库前，需要修改/tmp/pfile.ora 参数文件，将以下参数去除:

undo_management=manual

_allow_resetlogs_corruption=true

fast_start_parallel_rollback=high

重启:

startup force pfile='/tmp/pfile.ora';

create spfile from pfile='/tmp/pfile.ora';

startup force;

Author: halberd.lee

Created: 2019-06-20 Thu 10:38

Validate