ORA-00600:

内部错误代码

,

参数

: [13013]

数据库版本：

Oracle

11.2.0.1.0

数据库服务器操作系统：

Windows

server 2008

错误号

(1)

：

ORA-00600:internal error code, arguments:

[13013], [5001],

[267]

, [8460734], [2], [8460734], [17], [], [], [], []

详细报错如下

:

Mon May 30 11:40:28 2016

Errors in file

e:\app\administrator\diag\rdbms\klnew\klnew\trace\klnew_smon_2184.trc  (incident=93782):

ORA-00600: internal error code, arguments:

[13013],

[5001],

[267]

, [8460734], [2],

[8460734], [17], [], [], [], [], []

Incident details in:

e:\app\administrator\diag\rdbms\klnew\klnew\incident\incdir_93782\klnew_smon_2184_i93782.trc

Non-fatal internal error happenned while SMON was doing logging

scn->time mapping.

SMON

encountered 3 out of maximum 100 non-fatal internal errors.

Mon May 30 11:40:30 2016

问题现象

(1)

：

SMON

encountered 3 out of maximum 100 non-fatal internal errors.

数据库运行一段时间，实例自动关闭；

查看：

klnew_smon_2184_i93782.trc

========= Dump for incident 93782 (ORA 600 [13013]) ========

*** 2016-05-30 11:40:28.480

dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)

----- Current SQL Statement for this session

(sql_id=dma0vxbwh325p) -----

update

smon_scn_time

set time_mp

= :1,

time_dp      = :2,

scn          = :3,

scn_wrp      = :4,

scn_bas      = :5,

num_mappings = :6,

tim_scn_map  = :7

where scn = (select min(scn) from smon_scn_time)

错误号

(2)

：

ORA-00600:

internal error code, arguments:

[13011],

[267], [8460734]

, [2], [8460734], [17], [], [], [], [], [], []

详细报错如下：

Mon May 30 11:30:24 2016

Errors in file

e:\app\administrator\diag\rdbms\klnew\klnew\trace\klnew_smon_2184.trc  (incident=93780):

ORA-00600: internal error code, arguments:

[13011], [267],

[8460734]

, [2], [8460734], [17],

[], [], [], [], [], []

Incident details in:

e:\app\administrator\diag\rdbms\klnew\klnew\incident\incdir_93780\klnew_smon_2184_i93780.trc

Non-fatal internal error happenned while SMON was doing logging

scn->time mapping.

SMON

encountered 1 out of maximum 100 non-fatal internal errors.

Mon May 30 11:30:26 2016

问题现象

(2)

：

SMON

encountered 3 out of maximum 100 non-fatal internal errors.

数据库运行一段时间，实例自动关闭；

查看

klnew_smon_2184_i93780.trc

：

========= Dump for incident 93780 (ORA 600 [13011]) ========

*** 2016-05-30 11:30:24.650

dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)

----- Current SQL Statement for this session

(sql_id=gm9t6ycmb1yu6) -----

delete from

smon_scn_time

where scn = (select min(scn) from smon_scn_time)

错误号

(3)

：

ORA-00600:

internal error code, arguments:

[13013], [5001],

[456]

, [4338038], [0], [4338038], [17], [], [], [], [],

[]

详细报错如下：

Fri May 27 17:25:50 2016

Errors in file

e:\app\administrator\diag\rdbms\klnew\klnew\trace\klnew_smon_516.trc  (incident=90132):

ORA-00600: internal error code, arguments:

[13013],

[5001], [456]

, [4338038], [0],

[4338038], [17], [], [], [], [], []

Incident details in:

e:\app\administrator\diag\rdbms\klnew\klnew\incident\incdir_90132\klnew_smon_516_i90132.trc

Non-fatal internal error happenned while SMON was doing flushing of

monitored table stats.

SMON encountered 1 out of maximum 100 non-fatal internal errors.

问题现象

(3)

：

数据库无法通过

shutdown

immediate

方式关闭，只能通过

shutdown abort

关闭

查看：

klnew_smon_516_i90132.trc

========= Dump for incident 90132 (ORA 600 [13013]) ========

*** 2016-05-27 17:25:50.929

dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)

----- Current SQL Statement for this session

(sql_id=3c1kubcdjnppq) -----

update

sys.col_usage$

set equality_preds

= equality_preds +

decode(bitand(:flag, 1), 0, 0, 1),

equijoin_preds    = equijoin_preds +

decode(bitand(:flag, 2), 0, 0, 1),

nonequijoin_preds = nonequijoin_preds +

decode(bitand(:flag, 4), 0, 0, 1),

range_preds       = range_preds + decode(bitand(:flag, 8), 0, 0, 1),

like_preds        = like_preds + decode(bitand(:flag, 16), 0, 0, 1),

null_preds        = null_preds + decode(bitand(:flag, 32), 0, 0, 1),

timestamp         = :time

where obj# = :objn

and intcol# = :coln

解决方案：

ORA-00600:

[13013]

,

[5001]

,

[267]

ORA-00600:

[13011],

[267]

select * from dba_objects where object_id=

267;

select * from dba_ind_columns where table_name='

SMON_SCN_TIME';

ORA-00600:

[13013]

,

[5001],

[456]

select * from dba_objects where object_id=

456;

select * from dba_ind_columns where table_name=

'COL_USAGE$';

select

dbms_metadata.get_ddl('

INDEX','

I_COL_USAGE$','

SYS') from dual;

唯一索引里出现了重复数据

删除索引

I_COL_USAGE$，

重建

非唯一

索引；

其中

MOS

中查询有关

ORA-00600[13013]

问题相关信息；

New and

Improved: ORA-600 [13013] "Unable to get a Stable set of Records" (

文档

ID 1438920.1)

修改时间

:

2015-11-18

类型

:

TROUBLESHOOTING

***Checked for

relevance on 10-Jul-2015***

Note: For additional ORA-600 related

information please read

Note: 146580.1

PURPOSE:

This article is a new and improved copy of

OERI

Note: 28185.1

which is designed to pilot a new feature to help

identify known bugs for ORA-600[13013] issues. If you do not want to use the

new feature, please use the original

Note: 28185.1

.

The new feature available in this version

of the OERI note provides a list of conditions most commonly identified for

bugs related to this error. These conditions can be used to narrow down the

possible cause of the error. Our goal with this pilot is to determine if this

level of detail will lead our readers to a quicker resolution. After having

used this new feature, please email

with your feedback. Please provide

answers to the following:

Did this new feature help you identify the issue?

Did it save you research time?

Do you feel more confident with applying a

patch/patch set or using the workaround(if provided)?

Would you use this new feature again?

This article has been published because the

ORA-600 error has been reported in at least one confirmed bug.

ERROR:

Format: ORA-600 [13013] [a] [b] [c] [d] [e]

[f]

VERSIONS:

versions 6.0 and above

DESCRIPTION:

During the execution of an UPDATE

statement, after several attempts (Arg [a] passcount) we are unable to get a

stable set of rows that conform to the WHERE clause.

ARGUMENTS:

The number of arguments and their meaning

vary depending on the Oracle

Server release and the object types relating to the error.

2 Argument format

=================

This format relates to Oracle Server 8.0.4

and above and Index Only Tables (IOT)

Arg [a] Passcount

Arg [b] Code

5 Argument format

=================

This format relates to Oracle Server 6.0 to

7.3.4

Arg [a] Passcount

Arg [b] Code

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])

6 Argument format

=================

This format relates to Oracle Server 8.0.3

and above

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

FUNCTIONALITY:

Update Execute

IMPACT:

PROCESS FAILURE

POSSIBLE INDEX CORRUPTION

SUGGESTIONS:

This error could indicate a corrupt index.

Check for corrupted indices using the

following command :

ANALYZE TABLE  VALIDATE

STRUCTURE CASCADE;

Where  is the table being

updated.

Drop and recreate any indexes that show

problems.

On Parallel Server instances (OPS - Oracle

Server <= 7.X) this can be due to an inappropriate setting of

max_commit_propagation_delay. Setting this parameter to 0 can avoid this

error.

For 7.3.2 releases please see ALERT:

40673.1 ALERT: Incorrect Results or Internal Errors from Indexed Table Access

If the Known Issues section below does not

help in terms of identifying a solution, please submit the trace files and

alert.log to Oracle Support Services for further analysis.

KNOWN BUGS:

Select the items that meet the conditions of your

environment at the time of the error for a list of possible bugs.

To see details about each condition, click on the plus sign.

You can restrict the list below to conditions likely to affect one of

the following versions by clicking the relevant button:

Conditions for Version 11.2.0.1

ERROR

The second

argument is [5001] and the 6th argument is [17]

The second

argument is [5001] and the 6th argument is [3]

OBJECT

Bitmap

indexes are used

Error

logging is being used

SQL is using

hidden columns

Target table

has a NOT NULL added column with default value

There is a

specially added column being updated

Supplemental

logging is being used for the hidden column

A trigger is

being used in the SQL

SQL

SQL contains

one or more DELETE statements

SQL contains

a MERGE which has a view with a GROUP BY

SQL contains

MERGE statement with UPDATE

SQL contains

MERGE statement with update or delete clauses

Only one row

is updated or deleted by the SQL

SQL contains

UPDATE statement

SQL contains

UPDATE and a LONG column is being updated

UPDATE SQL

specifies rowid to be updated

TRACEFILE

Execution

plan shows "PX COORDINATOR FORCED SERIAL"

CONFIGURATION

The

initialization parameter Parallel_max_servers is set to a low number

Matches

Article Id

Type

Description

1 of 1

Patch/Patch Set and Workaround Available

Corrupt index after PDML

executed in serial. Wrong results. OERI[kdsgrp1]/ORA-1499 by analyze

1 of 1

Patch or Patch Set Available

Bitmap index corruption

by update or delete with error logging

Bug 9469117 - Corrupt index

after PDML executed in serial. Wrong results. OERI[kdsgrp1]/ORA-1499 by

analyze (

文档

ID

9469117.8)

修改时间

:

2013-6-28

类型

:

PATCH

Bug

9469117  Corrupt index after PDML executed in serial. Wrong

results. OERI[kdsgrp1]/ORA-1499 by analyze

This note gives a brief overview of bug

9469117.

The content was last updated on: 28-JUN-2013

Click

here

for details of each of the

sections below.

This bug is marked as an important issue.

Affects:

Product

(

Component

)

Oracle

Server (Rdbms)

Range

of versions

believed

to be affected

Versions

BELOW 12.1

Platforms

affected

Generic

(all / most platforms affected)

Fixed:

Description

Index maintenance is not being done for UPDATE/DELETE/MERGE statements

that UPDATE/DELETE only one row when a parallel plan (PDML) is executed in serial;

e.g., there are not enough parallel server processes.

Example:

alter session enable parallel dml;

update tbug set col1=30 where col1=9; -> this statement is executed in

serial instead of parallel and

updates one row only as col1 is a

unique key.

As the index is inconsistent with the table, this results in a corrupt index

causing wrong results or errors like:

ORA-600 [kdsgrp1]

ORA-600 [qertbFetchByRowID]

ORA-600 [13013] with error code 17 KDCMPF11 by an update

ORA-8102

ORA-1499 by "analyze table  validate structure cascade" with

a trace file containing error messages like:

"Table/Index row count mismatch"

"row mismatch in index"

Workaround

To avoid the problem:

Make sure that there are enough parallel server processes (increase parallel_max_servers)

or

Execute the DML statement in serial (disable Parallel DML).

To repair the index inconsistency, Drop/Create the index.

Please

note:

The above is a summary description only. Actual symptoms can

vary. Matching to any symptoms here does not confirm that you are

encountering this problem. For questions about this bug please consult

Oracle Support.

References

(This link

will only work for PUBLISHED bugs)

Note:245840.1

Information on the sections in this article

Bug 9229891 - Bitmap index

corruption by update or delete with error logging (

文档

ID

9229891.8)

修改时间

:

2016-5-27

类型

:

PATCH

Bug

9229891  Bitmap index corruption by update or delete with error

logging

This note gives a brief overview of bug

9229891.

The content was last updated on: 29-MAR-2016

Click

here

for details of each of the

sections below.

Affects:

Product

(

Component

)

Oracle

Server (Rdbms)

Range

of versions

believed

to be affected

Versions

BELOW 12.1

Versions

confirmed

as being affected

Platforms

affected

Generic

(all / most platforms affected)

Fixed:

Interim patches may be available for earlier versions - click

to

check.

Description

A Bitmap index can be missing keys after UPDATE or DELETE when

error logging is used (DBMS_ERRLOG.CREATE_ERROR_LOG).

Wrong result or next errors can be produced:

ORA-1499 by "analyze validate structure cascade" and trace file has:

"row not found in index"

ORA-600[13013] with error code 17 (KDCMPF11) by an update

Please

note:

The above is a summary description only. Actual symptoms can

vary. Matching to any symptoms here does not confirm that you are

encountering this problem. For questions about this bug please consult

Oracle Support.

References

(This link

will only work for PUBLISHED bugs)

Note:245840.1

Information on the sections in this article

High Executions Of Statement "delete from

smon_scn_time..." (

文档

ID 375401.1)

修改时间

:

2013-3-2

类型

:

PROBLEM

In this Document

APPLIES TO:

Oracle

Database - Enterprise Edition - Version 10.1.0.2 to 10.2.0.4 [Release 10.1 to

10.2]

Information in this document applies to any platform.

SYMPTOMS

A delete from smon_scn_time is

performing excessive gets and executions as viewed from AWR report:

Buffer Gets Executions Gets per Exec

%Total CPU Time (s) Elapsed Time (s)

205,501,888 30,508 6,736.00 54.05 9,733.97 61,180.96  delete from

smon_scn_time where...

The AWR report shows the following SQL with  an excessive amount of

executions:

delete from smon_scn_time where thread=0 and time_mp = (select min(time_mp)

from smon_scn_time where thread=0);

CAUSE

There

are inconsistencies between the indexes and table smon_scn_time.

The delete statement deletes the oldest rows from

smon_scn_time to clear space for new rows.  SMON wakes up every 5

minutes and checks how many on-disk mappings we have--the max is 144000.

The new mappings are then added for the last period

(since SMON last updated), and if this is over 144000, SMON will then issue

the delete statement:

delete from smon_scn_time where thread=0 and time_mp =

(select min(time_mp) from smon_scn_time where thread=0)

There will be an execution of this each time SMON wakes

to update smon_scn_time, and if one deletion does not free enough mappings,

then there will be multiple executions.

What happens is due to the inconsistency between the

table and indexes the delete returns zero rows; so the delete statement is

executed continuously to reduce the smon_scn_time below the maximum 14400

mappings.

When table smon_scn_time is analyzed we see the

inconsistency:

SQL> analyze table smon_scn_time validate structure

cascade;

analyze table smon_scn_time validate structure cascade

*

ERROR at line 1 :

ORA-01499: table/Index Cross Reference Failure - see

trace file

SOLUTION

To implement the solution, please

execute the following steps:

1. Ensure you have a usable backup in

case of failures

2. Drop and recreate the indexes on

table smon_scn_time

connect / as sysdba

drop index smon_scn_time_scn_idx;

drop index smon_scn_time_tim_idx;

create unique index smon_scn_time_scn_idx on smon_scn_time(scn);

create unique index smon_scn_time_tim_idx on smon_scn_time(time_mp);

analyze table smon_scn_time validate structure cascade;

欢迎关注我的微信公众号"IT小Chen"，共同学习，共同成长！！！