New and  Improved: ORA-600 [13013] "Unable to get a Stable set of Records" ( 文档 ID 1438920.1)

转到底部

***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  Vickie.Carbonneau  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:

Bug 9469117 - Corrupt index  after PDML executed in serial. Wrong results. OERI[kdsgrp1]/ORA-1499 by  analyze ( 文档 ID  9469117.8)

转到底部

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:

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.

References

Bug:9469117   (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)

转到底部

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:

Fixed:

Interim patches may be available for earlier versions - click   here   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

References

Bug:9229891   (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)

转到底部

In this Document

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.

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

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

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;