ORA-600 [13013] handling process

ORA-600 [13013] handling process

Record one ORA-600 [13013] Process

A ORA-600 [13013] error was found in the alert Log after a database exception was completed

Thu Mar 08 23:29:37 2012

Errors infile/opt/Oracle/diag/rdbms/chf/trace/chf_smon_24137.trc (incident = 38681 ):

ORA-00600: internal error code, arguments: [13013], [5001], [518], [4198427], [170], [4198427], [17], [], [], [], [], []

Incident details in:/opt/oracle/diag/rdbms/chf/incident/incdir_38681/chf_smon_24137_i38681.trc

Use ADRCI or Support Workbench to package the incident.

See Note 411.1 at My Oracle Support forerror and packaging details.

Non-fatal internal error happenned whileSMON was doing flushing of monitored table stats.

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

Trace file information
It can be seen from this that this error occurs due to the update operation on the sys. col_usage $ table.

Dump continued from file:/opt/oracle/diag/rdbms/chf/trace/chf_smon_24137.trc

ORA-00600: internal error code, arguments: [13013], [5001], [518], [4198427], [170], [4198427], [17], [], [], [], [], []

========= Dump forincident 38681 (ORA 600 [13013]) ========

* ** 23:29:37. 400

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

----- Current SQL Statement forthis session (SQL _id = 3c1kubcdjnppq )-----

Update sys. col_usage $ setequality_preds = equality_preds + decode (bitand (: flag, 1), 1), equijoin_preds = vertex + decode (bitand (: flag, 2 ),

, 1), nonequijoin_preds = nonequijoin_preds + decode (bitand (: flag, 4), 1), range_preds = range_preds + decode (bitand (: flag, 8, 1), like_preds

= Like_preds + decode (bitand (: flag, 16), 1), null_preds = null_preds + decode (bitand (: flag, 32), 1), timestamp =: timewhere obj # =: ob

Jn and intcol # =: coln
 

Description of ORA-600 [13013] in MOS

Format: ORA-600 [13013] [a] [B] {c} [d] [e] [f]

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
 

Description in Verify MOS

SQL> selectdbms_utility.data_block_address_file (4198427) rfile,

2 dbms_utility.data_block_address_block (4198427) blocks

3 fromdual;

RFILE BLOCKS

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

1 4123

SQL> SELECTOWNER, SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME, A. PARTITION_NAME

2 FROMDBA_EXTENTS

3 WHEREFILE_ID = & FILE_ID

4 AND & BLOCK_ID BETWEENBLOCK_ID ANDBLOCK_ID + BLOCKS-1;

Enter value forfile_id: 1

Old 3: WHEREFILE_ID = & FILE_ID

New 3: WHEREFILE_ID = 1

Enter value forblock_id: 4123

Old 4: AND & BLOCK_ID BETWEENBLOCK_ID ANDBLOCK_ID + BLOCKS-1

New 4: AND4123 BETWEENBLOCK_ID ANDBLOCK_ID + BLOCKS-1

OWNER SEGMENT_NAME SEGMENT_TY TABLESPACE PARTI

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

SYS COL_USAGE $ TABLESYSTEM

-- Consistent with the exception table in the trace file

SQL> selectobject_type, object_name fromdba_objects whereobject_id = 518;

OBJECT_TYPE OBJECT_NAME

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

TABLECOL_USAGE $

-- It is also consistent with the exception table in the trace file
 

Analysis exception table

SQL> ANALYZE TABLEsys. COL_USAGE $ VALIDATE STRUCTURE CASCADE;

ANALYZE TABLEsys. COL_USAGE $ VALIDATE STRUCTURE CASCADE

*

ERROR atline 1:

ORA-01499: table/indexcrossreference failure-see trace file

SQL> selectindex_name, COLUMN_NAME, COLUMN_POSITION FROMDBA_IND_COLUMNS

2 WHERETABLE_NAME = 'col _ USAGE $ ';

INDEX_NAME COLUMN_NAM COLUMN_POSITION

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

I _COL_USAGE $ OBJ #1

I _COL_USAGE $ INTCOL #2

SQL> setautot trace exp

SQL> SELECT/* + FULL (t1) */OBJ #, INTCOL #

2 FROMsys. COL_USAGE $ t1

3 MINUS

4 SELECT/* + index (t I _COL_USAGE $) */OBJ #, INTCOL #

5 FROMsys. COL_USAGE $ t whereOBJ # isnotnullorINTCOL # isnotnull;

Norowsselected

-- No record returned

Execution Plan

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

Plan hash value: 399371572

Bytes ------------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (% CPU) | Time

|

Bytes ------------------------------------------------------------------------------------

| 0 | SELECTSTATEMENT | 4262 | 76716 | 27 (71) | 00:00:01 |

| 1 | MINUS |

| 2 | sort unique | 4262 | 38358 | 9 (12) | 00:00:01 |

| 3 | tableaccess full | COL_USAGE $ | 4262 | 38358 | 8 (0) | 00:00:01 |

| 4 | sort uniquenosort | 4262 | 38358 | 18 (6) | 00:00:01 |

| * 5 | INDEXFULLSCAN | I _COL_USAGE $ | 4262 | 38358 | 17 (0) | 00:00:01 |

Bytes ------------------------------------------------------------------------------------

-- Verify that the two SQL statements in the table are correct (one full table scan and the other index quick scan)

SQL> SELECT/* + index (t I _COL_USAGE $) */OBJ #, INTCOL #

2 FROMsys. COL_USAGE $ t whereOBJ # isnotnullorINTCOL # isnotnull

3 MINUS

4 SELECT/* + FULL (t1) */OBJ #, INTCOL #

5 FROMsys. COL_USAGE $ t1;

OBJ # INTCOL #

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

4294951004 2

4294951004 3

4294951004 4

4294951004 26

4294951004 27

4294951037 4

4294951037 5

4294951037 6

4294951037 9

4294951037 10

4294951840 11

OBJ # INTCOL #

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

4294951840 12

4294951906 4

4294952709 3

4294952867 4

4294952867 9

16 rowsselected.

-- Proves that there are 16 more records in the index than in the table
 

Resolve and verify the problem

SQL> alterindexsys. I _COL_USAGE $ rebuild online;

Indexaltered.

SQL> SELECT/* + FULL (t1) */OBJ #, INTCOL #

FROMsys. COL_USAGE $ t1

2 3 MINUS

4 SELECT/* + index (t I _COL_USAGE $) */OBJ #, INTCOL #

5 FROMsys. COL_USAGE $ t whereOBJ # isnotnullorINTCOL # isnotnull

6;

Norowsselected

SQL> SELECT/* + index (t I _COL_USAGE $) */OBJ #, INTCOL #

2 FROMsys. COL_USAGE $ t whereOBJ # isnotnullorINTCOL # isnotnull

3 MINUS

4 SELECT/* + FULL (t1) */OBJ #, INTCOL #

5 FROMsys. COL_USAGE $ t1;

Norowsselected

This problem occurs because an index is used to locate a record in the update statement and the record does not exist when it is queried in the table. The general solution is to re-create the index.

Migration from 32-bit to 64-bit for a single Oracle instance

Install Oracle 11gR2 (x64) in CentOS 6.4)

Steps for installing Oracle 11gR2 in vmwarevm

Install Oracle 11g XE R2 In Debian