Section 1> What information needs to be Collected

ORA-600 [13013] [a] [b] [c] [d] [e] [f]

This format relates to Oracle Server 8.0.3 to 10.1

Arg [a] Passcount
Arg [b] Data Object number
Arg [c] Tablespace Relative DBA of block containing the row to be updated
Arg [d] Row Slot number
Arg [e] Relative DBA of block being updated (should be same as [c])
Arg [f] Code

The Second argument would give the information about the data object id.

This would give information about the object involved.

SQL>select object_name,object_type,owner from dba_objects where data_object_id=<value repo
rted in argument b> ;

Once the Object is identified run the following :

The below command check if the table has corruption or not .
SQL> Analyze table <owner>.<table name> validate structure online ;
If this goes fine table does not have corruption. For next command.
If the above command fails with ORA-1498 go to Section 3

The below command check if table/index has corruption or not

SQL>Analyze table <owner>.<table name> validate structure cascade online ;

If the above command errors out with ora-1499 it indicates a corruption in index.

Go to section 2 for resolution

Run dbverify on the datafile reported in the error

Arg [c] in the ora-0600[13013] would give the Relative DBA

For example
ORA-00600: internal error code, arguments: [13013], [5001], [57353], [155254965], [261],
[155254965], [17], []
Arg [c] --> rdba-->155254965

Use this value and find the file and block number for this dba
select dbms_utility.data_block_address_file(155254965) Rfile#, dbms_utility.data_block_addre
ss_block(155254965) "Block#" from dual;
RFILE# Block#
---------- ----------
37 65717
Run dbverify on datafile with rfile#=37:
SQL> select name, block_size from v$datafile where rfile#=37;
$ dbv file=<location of datafile> blocksize=<block_size>

Section 2 >How to resolve if a Index is corrupted

You would need to drop and recreate the index
Ensure before dropping the Index
SQL>Spool /tmp/createindex.sql
SQL>Set long 100000000
SQL>Select dbms_metadata.get_ddl('INDEX','<Index name>',<'user name>') from dual
SQL>Spool off

Refer the Following note to Identify the index

Note 563070.1
Title: ORA-1499. Table/Index row count mismatch
Please note if there is just one index in the table then you can use dbms_metadata.get_ddl to get
the script of the index and drop and recreate it.

Section 3> How to resolve if table is corrupted

Option a> Backup is available
Ora-1498 would be reported on the table.
The trace file from Ora-1498 would contain following information
Example
Block Checking: DBA = 1066265208, Block Type = KTB-managed data block --->
file 254,block 911992
data header at 0xc00000010118e07c
kdbchk: avsp(816) > tosp(812)
Block header dump: 0x3f8dea78
Object id on Block? Y
seg/obj: 0x155b452 csc: 0x05.7b2b4ee6 itc: 3 flg: E typ: 1 - DATA
brn: 0 bdba: 0x3f8dde0c ver: 0x01
inc: 0 exflg: 0

Note the DBA value reported in the trace file DBA = 1066265208
Convert this to find the file number and block number having issue
Sql>select dbms_utility.data_block_address_file('1066265208') from dual ;
DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE('1066265208')
--------------------------------------------------
254
Sql>Select dbms_utility.data_block_address_block('1066265208') from dual ;
DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK('1066265208')
---------------------------------------------------
911992

Run dbverify on the datafile containing the table

dbv file=<location of datafile> blocksize=<db_block_size>

Corruption would be reported on the block.

If you have an Rman backup do a Rman block recovery (Take the file number and block number
affected from the trace file)
Rman> Blockrecover datafile <no> block <block number>
Or
If you have a user managed backup you can do an restore and recovery from good copy of the
problematic datafile

Option b> Backup is not available

If no backups are available then use event 10231 at session level to create a salvage table
SQL>alter session set events '10231 trace name context forever, level 10'
SQL> Create table <owner>.salvage_table as select * from <Corrupted table> ;

Rename the Original table to old.

Rename salvage table to Original table name
or
You can use dbms_repair script to mark the block soft corrupt.
Note 556733.1
DBMS_REPAIR SCRIPT

How to resolve when SMON terminates the instance due to ORA-00600 [13013]
If smon is terminating the instance then.
Set event 10513 and startup the database
event="10513 trace name context forever, level 2"
SQL>startup mount ;
SQL>show parameter event
SQL>alter datatabase open ;
Identify the object involved using information from Section 1.

How to resolve the issue if the object involved belongs to system tablespace
System objects are very important.
Please open a Service request with Oracle support if system tables are involved.

Identifying the row having issue when the table is having corruption.
1. Once the error occurs, using the ORA-600 arguments, gather the following information :
ORA-00600: internal error code, arguments: [13013], [5001], [57353], [155254965], [261],
[155254965], [17], []
arg b : [57353] - it is the OBJECT_ID
arg c : [155254965] - it is the block address in Decimal
arg d : [261] - is it the slot number

2. Translate the the block address in Decimal to a file# and block #

select dbms_utility.data_block_address_file(155254965) Rfile#, dbms_utility.data_block_addres
s_block(155254965) "Block#" from dual;

RFILE# Block#
---------- ----------
37 65717

The Relative file is 37

The block number is 65717

Find the data_object_id for this object

Argument b is Object_id--> 57353

SQL>Select data_object_id ,object_name,owner from dba_objects where object_id=57353 ;

3. Create the rowid using:

dbms_rowid.rowid_create(1,DATA_OBJECT_ID,FILE#,BLOCK#,SLOT#)
In this case :
select dbms_rowid.rowid_create(1,57353,37,65717,261) from dual;
DBMS_ROWID.ROWID_C
-------------------------------
AAAOAJAAlAAAQC1AEF

4. You can select from table and identify the record causing the issue
SQL> Select * from <owner>.<table name> where rowid='AAAOAJAAlAAAQC1AEF';

ORA-00600 basically means you've crash the oracle server (not the instance, just the server servi
cing your request).

There will almost always be a trace file in your bdump location. This likely wont be a lot of help
you to, but will be very helpful to oracle support.

This is generally caused by an oracle bug, and from experience, there isn't a lot you can do about
them except raise a SR via metalink (this is the recommended solution from Oracle). They will try
to replicate the issue and with any luck, if its a bug it will eventually find its way into a patch.

In the immediate term though (eg, days - months) the main realistic solution is work around it.

While raising the SR doesn't really do alot to help you and can be a frustrating experience, its
worth doing, as it might save someone else time once the bug is fixed.

These bugs are usually related to the optimizer. I think even the smallest change in the query like
switching the order of table1 and table2 in the FROM clause might force the optimizer to choose a
different plan that will not encounter this error.

ORA-00600 generally means that there is something highly unexpected and it might be linked to
the database corruption. The symptoms can be that query works or not depending on how it is
formulated.

Life example:
LOB field update went wrong for a particular row with id=<ID>
The row is not visible with SELECT * FROM <table>
But: SELECT * FROM <table> WHERE id=<ID> fails to execute and gives ORA-006000.
(Possible) Solution used to the above example
export all accessible table contents
delete table
reimport the contents

Oracle is trying to get a stable set of rows to update and could not, after 5001 attempts.
Here is what the arguments mean:
[13013] ==> indicates the problem is a failure to identify a stable set of rows to update
[5001] ==> the number of times Oracle tried
[1675658] => The data object number (SELECT * FROM DBA_OBJECTS WHERE
DATA_OBJECT_ID = 1675658)
[773963968] => Tablespace-relative data block address
[10] ==> row slot number
[773963968] ==> decimal relative data block address of block being updated
[17] ==> internal code
[] ==> not used

What to try:
First, check for block corruption in your table's indexes: ANALYZE TABLE <table_name>
VALIDATE STRUCTURE CASCADE. Then drop and re-create and indexes that show problems.

General, more useful answer

OK, how did I know all of the above (assuming it's even correct)?...
"ORA-00600", "ORA-00700", and "ORA-07445" errors are internal Oracle errors. The only entity
really capable of diagnosing/explaining/fixing them is Oracle Corporation. To that end, Oracle
provides a diagnostic tool on their support website: http://support.oracle.com. It is document ID
153788.1 on their site (though you can also just search on their site for "ORA-600 tool").

Using that tool, you enter the specifics of your ORA-00600 error (usually just the first argument -
"13013", in your case) and, if you're lucky, it will redirect you to a note telling you all about it.

This might be caused by Oracle memory corruption.

Try -
a) Drop and recreate Indexes on both the tables used in the query.
b) Flush the database cache memory
c) Try adding the table owner prefix at the session level

This is not random try, I had this issue in the past for 4-5 times and I went through the internet and
found this solution that worked for me. I have this solution noted down in my notes.