Record A ORA-600 [13013] processing process and an alert Log with a ORA-600 [13013] error found after a database exception is completed
Record A ORA-600 [13013] processing process and an alert Log with a ORA-600 [13013] error found after a database exception is completed
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