ORA-600错误分析

‍作者简介：种英明，ORACLE数据库工程师,就职于北京海天起点南京分公司，拥有多年数据库开发，管理，维护经验，获有ORACLE OCP和MySQL OCP证书，擅长ORACLE安装升级，故障处理以及sql优化，了解SQL Server,Sybase等多种数据库技术。 

概述

ORA-600错误是一般oracle程序异常的内部错误，它表明一个进程遇到了一个低级的、意外的情况。Ora-600错误发生的时候，后面的方括号内会有一个参数列表。格式：ORA 600 “internal error code, arguments: [%s], [%s],[%s], [%s], [%s]”。

第一个参数是内部消息号或字符串，这个参数和数据库版本号对找到Ora-600的根本原因和潜在影响至关重要。剩余的参数是用来提供进一步的信息。

第一个参数可以帮助缩小问题范围。可以认为是由Oracle的源代码很多地方引用的功能。ora-600trace文件里有更详细的调用堆栈信息，可以帮助我们找到一个解决方案。

ORA-600错误对数据库管理员来说并不陌生，总会遇到过那么几次。一旦遇到ORA-600错误不要简单的认为就是oracle软件 bug导致，其实这种错误，不仅种类很多而且有很多原因导致的，包括oracle bug，断电，内存错误，程序异常，讹传等，需要根据错误种类具体去分析。

本文通过一个ORA-600多种错误的故障案例，分析这种错误产生的原因，以及解决方法。为以后数据库管理人员提供一个借鉴和参考，避免走弯路。

案例

描述

ORA-00600[4194] 错误一般是由于重做记录号和最大的回滚记录号不一致导致的，格式：”ORA-600 [4194] [a] [b]”。

第一个参数就是最大的回滚记录号，第二个参数重做记录号。

当然还有很多其他的原因导致ORA-00600 [4194] 错误,比如说smon执行事务恢复，回滚段冲突或者损坏，oracle bug等。

通过查看alert日志，部分内容如下：

Fri Apr 07 17:13:05 2017

Errors in file oracle/app/diag/rdbms/test/test/trace/test_ora_16389.trc  (incident=343469):

ORA-00603: ORACLE server session terminated by fatal error

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

...

从alert日志来看4194后面的参数都是空的，不是两个记录号不一致的原因,如果需要进一步确定原因，需要查看对应的 trace文件：test_ora_16389.trc，trace部分内容如下：

DDE: Problem Key 'ORA 600 [4194]' was flood controlled (0x6) (incident: 343446)

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

*** ktuc_diag_dmp: dump of current change vector

ktudb big redo: cnt: 1 um: 0x1f39d11d0 uba: 0x00c001d4.da21.04

*** ktuc_diag_dmp: dump of block after image in hex

Dump of memory from 0x00000001CF510000 to 0x00000001CF518000

1CF510000 0000E202 00C001D4 8855A6D7 04010000  [..........U.....]

……………省略一部分…………………….

Dump of buffer cache at level 4 for tsn=2 rdba=12583380

BH (0x1cffdbf48) file#: 3 rdba: 0x00c001d4 (3/468) class: 36 ba: 0x1cf510000

  set: 11 pool: 3 bsz: 32768 bsi: 0 sflg: 2 pwc: 0,0

  dbwrid: 0 obj: -1 objn: 0 tsn: 2 afn: 3 hint: f

  hash: [0x1f9fa1260,0x1f9fa1260] lru: [0x1cffdc160,0x1cffdbf00]

  obj-flags: object_ckpt_list

  ckptq: [0x1cffe2568,0x1f8a32360] fileq: [0x1cffe2578,0x1f8a323c0] objq: [0x1ec8c8b78,0x1c8fd1a18] objaq: [0x1cffe2688,0x1c8fd3b68]

  use: [NULL] wait: [NULL]

  st: XCURRENT md: NULL fpin: 'kcbwh2: kcbchg1' tch: 1 txn: 0x1f50cd960

  flags: buffer_dirty mod_started private block_written_once

  change state: NOT_ACTIVE_YET

  change count: 1

  LRBA: [0x6e34.192b.0] LSCN: [0x0.885ef500] HSCN: [0x0.885ef500] HSUB: [65535]

*** ktuc_diag_dmp: dump of redo for rdba 0x00c001d4

上面的trc文件里面也没有4194后面详细的参数信息，只有一些数据块后镜像的dump信息，没有其他重要信息。可以判断file#: 3（经过查询，是undo表空间的数据文件）有问题，而且trc文件的xid又比较多，几乎在各个回滚段都存在。

解决方法

由于不适合对单个回滚段进行offlink或者drop，而且数据库现在还可以正常打开，于是通过下面的方法重建undo表空间：

1.    创建新的undo表空间

create undo tablespace undotbs2 datafile '/data/数据库名称/undotbs2.dbf' size 30g

2.    切换UNDO表空间为新的UNDO表空间

alter system set undo_tablespace=undotbs2;

3.    删除原来的undo表空间

drop tablespace undotbs1 including contents;

描述

ORA-00600[kdsgrp1] 错误原因有很多，比如说并行的DML,索引坏块，数据坏块，CR读，Buffercache数据块不一致。

由于数据库已经宕了多次，Buffer cache的数据不一致可以排除，暂时无法排除其他错误原因。

Alert日志部分内容如下：

Use ADRCI or Support Workbench to package the incident.

See Note 411.1 at My Oracle Support for error and packaging details.

Errors in file oracle/app/diag/rdbms/test/test/trace/test_m004_14600.trc  (incident=511761):

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

ORA-06512: at "SYS.PRVT_ADVISOR", line 6082

ORA-06512: at line 1

相关错误比较多，根据alert日志内容查找 kdsgrp1错误对应的trace文件，这个mmon进程的trace文件，几乎所有的错误都在这个trc文件：test_m004_14600.trc 部分内容如下：

* kdsgrp1-1: *************************************************

            row 0x0080079a.75 continuation at

            0x0080079a.75 file# 2 block# 1946 slot 117 not found

KDSTABN_GET: 0 ..... ntab: 1

curSlot: 117 ..... nrows: 105

kdsgrp - dump CR block dba=0x0080079a

Block header dump:  0x0080079a

Object id on Block? Y

seg/obj: 0x16b9  csc: 0x00.8861f1ef  itc: 2  flg: E  typ: 1 - DATA

     brn: 0  bdba: 0x800796 ver: 0x01 opc: 0

     inc: 0  exflg: 0

……………省略一部分……………………

* kdsgrp1-2: *************************************************

Incident 511760 created, dump file: oracle/app/diag/rdbms/test/test/incident/incdir_511760/test_m004_14600_i511760.trc

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

在trc文件里，没有找到sql的信息，也没有坏块的问题。在test_m004_14600.trc文件最后一部分，又提供了两个incident 文件：test_m004_14600_i511760.trc，test_m004_14600_i511761.trc，这两个incident文件里没有其他的报错信息也没有kdsgrp1错误更详细的信息。但是可以根据file# 2 block# 1946 信息，可以判断所在的对象有问题，查询这个数据块上的对象:

file#2 block# 1946 是属于SYS.WRI$_ADV_EXECUTIONS表，表空间是: SYSAUX，可以使用dbv工具检查这个数据文件，但是没有任何的错误信息。说明数据文件物理上没有损坏。可以基本上判断没有找到对应的数据行。

解决方法

对SYS.WRI$_ADV_EXECUTIONS表执行一致性检查：

Analyze table SYS.WRI$_ADV_EXECUTIONS validate structure online;

Analyze table SYS.WRI$_ADV_EXECUTIONS validate structure cascade online;

执行第一个语句没有问题，说明表结构没有问题。执行第二条语句，出现错误，生成trace文件：test_ora_8604.trc，文件部分内容如下：

kdgDump: tsn=1 tabn=0

         Current Row Piece: rdba=0x00800799 slot=0

         Head Row Piece:    rdba=0x00800799 slot=0

kdgDumpRedo: dump redo on table/index mismatch:

             table block tsn=1 rdba=0x00800799 index objn=5821

             head rowid 0x00800799.0000

*************************************

* kdgDumpRedo: dump data block redo *

*************************************

通过上面的文件信息”table/index mismatch”，可以判断是数据不一致。于是重建索引。

select index_name from dba_indexes t where t.owner='SYS' AND table_name='WRI$_ADV_EXECUTIONS';

Alter index index_name rebuild online;

再次执行一致性检查，没有报错。

描述

ORA-00600[13011] 错误一般是DML语句引起的，无法获取一个稳定的数据集，格式：”ORA-600 [13011][a] [b] [c] [d] [e]”,数据库版本至少8.0.3,下面是mos上对这个参数说明：

Arg [a] Passcount

Arg [b] Data Object number

Arg [c] Tablespace Decimal Relative DBA (RDBA) of block containing the row to be updated

Arg [d] Row Slot number

Arg [e] Decimal RDBA of block being updated (Typically same as [c])

Arg [f] Code

之前的两个错误解决之后，过一段时间，用户反馈，这个数据库实例又宕了，查看alert日志，内容如下：

Errors in file oracle/app/diag/rdbms/test/test/trace/test_smon_24580.trc  (incident=535689):

ORA-00600: internal error code, arguments: [13011], [183830], [8409015], [6], [8409015], [17], [], [], [], [], [], []

Incident details in: oracle/app/diag/rdbms/test/test/incident/incdir_535689/test_smon_24580_i535689.trc

Use ADRCI or Support Workbench to package the incident.

……………省略一部分……………………

Tue Apr 11 19:36:28 2017

Errors in file oracle/app/diag/rdbms/test/test/trace/test_smon_24580.trc  (incident=547590):

ORA-00600: internal error code, arguments: [13013], [5001], [183830], [8409015], [6], [8409015], [17], [], [], [], [], []

偶尔有ora-600 kdsgrp1 错误，查看trcce文件，还是报” file# 2 block# 2090 slot 64 not found “这种错误。另外多了ORA-00600: [13013]错误,根据13013后面的参数，数据库有问题的对象主要集中在8409015和183830上。

对应的trc文件：test_smon_24580.trc，基本上是一些数据块的dump的内容，没有”file# block#”之类信息或者其他重要信息。

由于出现错误的对象比较多，也为了防止后期还会出现同样的错误，所以对整个数据库sys对象进行检查。

解决方法

1. 使用mos提供的hcheck4.sql脚本，可以从文档 ID 136697.1上面下载，这个脚本用于检查数据字典是否有错误，执行方法如下：

$ sqlplus as sysdba

SQL> set serveroutput on size unlimited

SQL> spool outputfile

SQL> @hout.sql

SQL> @hcheck4.sql

SQL> spool off

查看生成的文件，数据字典没有问题

2.    使用如下sql生成analyze.sql脚本，用于检查所有sys用户的表一致性。

Set verify off

Set space 0

Set line 120

Set heading off

Set feedback off

Set pages 1000

Spool analyze.sql

Select 'Analyze cluster "'||cluster_name||'" validate structure cascade;'

from dba_clusters

where owner='SYS'

union

Select 'Analyze table "'||table_name||'" validate structure cascade;'

from dba_tables

where owner='SYS' and partitioned='NO' and (iot_type='IOT' or iot_type is NULL)

union

Select 'Analyze table "'||table_name||'" validate structure cascade into invalid_rows;'

from dba_tables

where owner='SYS' and partitioned='YES';

spool off

执行上面生成的analyze.sql 脚本。

在执行结果里面找ORA-01499 table/index cross reference failure错误，也就是表和索引信息不一致的表的信息。大概有30多张表。

set pagesize 999

select 'Alter index '||index_name||' rebuild online;' from dba_indexes t where t.owner='SYS' AND table_name in (

30多张表

）

最后对这30多张表的索引进行重建。

Rebuild索引时，可能会出现WRH$_PGASTAT表里复合主键上重复数据导致rebuild失败，删除重复数据，然后再次rebuild这个表上的索引。

中国OCM之家

专注数据    共现梦想

QQ群：554334183