An error solution for ORA-600 [13011]
Sunoperating 5.10
Oracle 10.2.0.2.0
A ORA-600 error occurs in a database in the development environment.
Error message in alert. log:
Thu Nov 13 15:11:43 2014
Errors in file/oracle/admin/sun/bdump/sun_j000_29589.trc:
ORA-00600: internal error code, arguments: [13011], [298314], [4277430], [0], [4277430], [17], [], []
Thu Nov 13 15:11:45 2014
Errors in file/oracle/admin/sun/bdump/sun_j000_29589.trc:
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
ORA-06512: at "REPADMIN. CEF_PUSH_PURGE", line 145
ORA-06512: at line 1
In the/oracle/admin/sun/bdump/sun_j000_29589.trc trace file, you can see that the current SQL statement deletes a record of system. def $ _ aqcall:
Ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [13011], [298314], [4277430], [0], [4277430], [17], [], []
Current SQL statement for this session:
Delete from system. def $ _ aqcall where (enq_tid =: 1)
Compare the parameters of MOS ORA-600 [13011] "Problem occurred when trying to delete a row" (Document ID 28184.1;
SQL> select object_type, object_name, owner from dba_objects where data_object_id = '20140901 ';
OBJECT_TYPE OBJECT_NAME OWNER
-----------------------------------------------------------------------------------------
Table def $ _ AQCALL SYSTEM
For the DEF $ _ AQCALL table, this table is the default team list for Advanced Replication, from ORA-06512: at "REPADMIN. CEF_PUSH_PURGE ", line 145 also shows that there is indeed a problem with Advanced Replication. After the replication is completed in time, the table will be cleared.
This ora-600 error is reported because an index is used in the update statement to locate a record and the record does not exist when it is queried in the table. The general solution is to recreate the index.
First, analyze the table:
SQL> analyze table system. DEF $ _ AQCALL validate structure cascade;
Analyze table system. DEF $ _ AQCALL validate structure cascade
*
ERROR at line 1:
ORA-01499: table/index cross reference failure-see trace file
SQL> select index_name, owner, status from dba_indexes where table_name = 'def $ _ AQCALL ';
INDEX_NAME OWNER STATUS
--------------------------------------------------------------------
Sys_il00000000004c00025 $ SYSTEM VALID
SYS_C001407 SYSTEM VALID
DEF $ _ TRANORDER SYSTEM VALID
SQL> select index_name, column_name, column_position from dba_ind_columns where table_name = 'def $ _ AQCALL ';
INDEX_NAME COLUMN_NAME COLUMN_POSITION
---------------------------------------------------------------------------
SYS_C001407 ENQ_TID 1
SYS_C001407 STEP_NO 2
DEF $ _ tranorder cscn 1
DEF $ _ TRANORDER ENQ_TID 2
Comparison data: full table scan and index data comparison:
SQL> select/* + index (t DEF $ _ TRANORDER) */CSCN, ENQ_TID from system. DEF $ _ AQCALL where CSCN is not null or ENQ_TID is not null
2 minus
3 select/* + FULL (t1) */CSCN, ENQ_TID from system. DEF $ _ AQCALL
4/
CSCN ENQ_TID
----------------------------------------
4755684454 8.37.2233719
4755684456 3.14.2235620
4755684458 8.2.2231049
4755684460 10.30.2223096
Sure enough, there are four more records on the index than on the table.
Rebuilding indexes online:
SQL> alter index system. DEF $ _ TRANORDER rebuild onlie;
Index altered.
Compare the index and table data again:
SQL> select/* + index (t DEF $ _ TRANORDER) */CSCN, ENQ_TID from system. DEF $ _ AQCALL where CSCN is not null or ENQ_TID is not null
2 minus
3 select/* + FULL (t1) */CSCN, ENQ_TID from system. DEF $ _ AQCALL
4/
No rows selected
No redundant data, through monitoring of alert. log, no subsequent ora-600 [13011] error was found.
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