typically starting with an ORA-600. It is
usually, but not always, the case that the
first is the significant error and the others
are side effects.
Code Listing 2: Find the index
CAN I RESOLVE THESE ERRORS MYSELF?
For some ORA-600 and ORA-7445 errors,
you can either identify the cause and resolve
the error on your own or find ways to avoid
the error. The information provided in this
section will help you resolve or work around
some of the more common errors.
ORA-600 [729]. The first argument to this
ORA-600 error message, 729, indicates a
memory-handling issue. The error message
text will always include the words space leak,
but the number after 729 will vary:
SELECT owner, segment_name, segment_type, partition_name
FROM DBA_SEGMENTS
WHERE header_file = (SELECT file#
FROM v$datafile
WHERE rfile# = dbms_utility.data_block_address_file(to_
AND ts#= &tsn)
AND header_block = dbms_utility.data_block_address_block(to_
number('&rdba','XXXXXXXX'));
example above, you could set the number to
1000, in which case the event instructs the
database to ignore all user space leaks that
are smaller than 1000 bytes.
ORA-600 [kddummy_blkchk]. The
kddummy_blkchk argument indicates that
checks on the physical structure of a block
have failed. This error is reported with three
additional arguments: the file number,
the block number, and an internal code
indicating the type of issue with that block.
The following is an alert.log excerpt for an
ORA-600 [kddummy_blkchk] error:
SQL>analyze index <indexname>
validate structure;
If there is definitely a corruption in the
object, the error returned will be
ORA 1498 "block check failure -
see trace file"
ORA-00600: internal error code,
arguments: [729], [800],
[space leak], [], [],
A space leak occurs when some code does
not completely release the memory it used
while executing. In this example, when that
process disconnected from the database,
it discovered that some memory was not
cleaned up at some point during its life and
reported ORA-600 [729]. The number in the
second set of brackets (800) is the number
of bytes of memory discovered.
You cannot determine the cause of the
space leak by checking your application
code, because the error is internal to Oracle
Database. You can, however, safely avoid the
error by setting an event in the initialization
file for your database in this form:
Errors in file/u01/oracle/admin/
PROD/bdump/ prod_ora_11345.trc:
ORA-600: internal error code, arguments:
[kddummy_blkchk], [ 2], [21940], [6110],
[], [], [], []
The best way to resolve the corruption
is to restore a copy of the affected datafile
from before the error and to recover the
database so these changes are applied to
the restored datafile and brought forward to
the current time. This action is possible only
if the archivelog feature for your database
is enabled. (Enabling this feature ensures
that all changes to the database are saved in
archived redo logs.)
ORA-600 [6033]. This error is reported with
no additional arguments, as shown in the
following alert.log file excerpt:
The ORA-600 [kddummy_blkchk] error
message usually reports a corruption, so
to identify the object involved, first use the
file number (&afn) and the block number
(&bn) reported in the error message in the
SQL query:
Errors in file/u01/oracle/admin/PROD/
bdump/ prod_ora_2367574.trc:
ORA-600: internal error code, arguments:
[6033], [], [], [], [], [], [], []
event="10262 trace name
context forever, level xxxx"
or by executing the following:
SQL>alter system set events
'10262 trace name context forever,
level xxxx' scope=spfile;
You will also need to shut the database
down and restart it to enable the event to
take effect.
Replace xxxx with a number greater than
the value in the second set of brackets in
the ORA-600 [729] error message. In the
select from dba_extents
where file_id=&afn
and &bn between block_id
and block_id + blocks – 1;
&afn is the first additional argument ( 2 in
this example); &bn is the second additional
argument (21940 in this example).
If the query returns a table, confirm the
corruption by executing
SQL>analyze table <tablename>
validate structure;
If the query returns an index, confirm the
corruption by executing
The ORA-600 [6033] error often indicates
an index corruption. To identify the affected
index, you’ll need to look at the trace file
whose name is provided in the alert.log file,
just above the error message. In this alert.log
excerpt, the trace file you need to look at is
called prod_ora_2367574.trc and is located
in /u01/oracle/admin/PROD/bdump.
