bendito error generico ORA-00600

copio la informacion que seguí paso a paso de esta URL: http://oraclemamukutti.blogspot.com/2011/06/ora-00600-13013-5001.html

por si acaso se llegan a encontrar con el tema que no saben donde ubicar los archivos de log que tienen el error, se puede usar:

select value from v$parameter where name = 'USER_DUMP_DEST'

por otro lado si desean una ubicacion en donde se puede localizar, les dejo esta ruta:

/app/oracle/diag/rdbms/prod/prod/trace/prod_ora_4303.trc

y dentro de ese archivo se debe buscar la cadena: mismatch

Ora - 00600 [13013], [5001]

I experience an Ora-00600 error. Let's look what is the error and the way to resolve it.

Error received

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

ORA-00600: internal error code, arguments: [13013], [5001], [4722], [29361923], [9], [29361923], [17], []

Let's look into details of how to solve this issue.

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

Once the Object is identified run the following :

The below command check if the table has corruption or not .

SQL> Analzye table . validate structure online;

If this goes fine table doesnot 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> Analzye table . 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[13011] would give the Relative DBA

For example

ORA-00600: internal error code, arguments: [13013], [5001], [57353], [155254965], [261], [151062605], [17], []

Arg [c] --> rdba-->155254965

Use this value and find the file and block number for this dba(data block address)

SQL> select dbms_utility.data_block_address_file(155254965) Rfile# ,dbms_utility.data_block_address_block(155254965) "Block#" from dual;

RFILE# Block#

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

37 65717

You can run dbveirfy on datafile with rfile#=37

SQL> Select name from v$datafile where rfile#=37;

$ dbv file= blocksize=

Section 2 > How to resolve if an 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','',<'user name>') from dual; 
SQL> Spool off

To Identify the index please do the following

Analyze table with "validate structure cascade" fails with ORA-1499 and the trace file contains message "Table/Index row count mismatch". Example:

SQL> analyze table test validate structure cascade;
analyze table test validate structure cascade
*
ERROR at line 1:
ORA-01499: table/index cross reference failure - see trace file 

The associated trace file contains:

Table/Index row count mismatch 
table 6559 : index 10000, 0 
Index root = tsn: 6 rdba: 0x01400091

It means: A table scan returned 6559 rows and an index scan returned 10000 rows. 
"Index root" is the segment header information for the index: 
rdba: 0x01400091 is the Index segment header relative data block address. It is decimal 20971665 which is Rfile#=5 Block#=145 :

SQL> select dbms_utility.data_block_address_file(20971665)  "Rfile#"   
2          ,dbms_utility.data_block_address_block(20971665) "Block#"   
3 from dual;   

Rfile#     Block#   
---------- ----------   
5          145  

Running the next query can identify the associated index:

QUERY 1:  

SQL> select owner, segment_name, segment_type  
2    from  dba_segments  
3    where header_file = 5  
4      and header_block = 145;  

OWNER    SEGMENT_NAME    SEGMENT_TYPE  
-------- --------------- ------------------  
SCOTT    I_TEST          INDEX 

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= blocksize=

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

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 .salvage_table as select * from ;

Rename the Original table to old.

Rename salvage table to Original table name

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.