ORA-00600 [25027] [x] [0] Raised by Insert into LOB (Doc ID 1608861.1)
In this Document
Symptoms
Cause
Solution
References
Applies to:
Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Cloud Exadata Service - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Oracle Database Cloud Schema Service - Version N/A and later
Information in this document applies to any platform.
Symptoms
Inserts,updates to table with LOB fail with ORA-00600 [25027] [x] [0] where x is the tablespace number (ts#) for the tablespace that has the LOB.
Trace file shows the stack function similar to:
krtd2abh kcbgcur ktspgfblk3 ktsplbfmb ktsplbrecl ktspgsp_main kdlgsp_init kdl_write1 kdlf_write koklicbf koklcre
Cause
The cause of this error can be LOST IO which may produce other errors like ORA-600 [kdlpdba:kcbz_objdchk] during INSERT.
The problem described in Bug 13869187 is because a Block is marked as Formatted in the ASSM metadata L1 bitmap block but the block is unformatted for the LOB segment.
The 3rd argument may not be always 0 (zero) as the problem is that if the block is unformatted, Oracle still tries to locate a pdba assuming that the block is formatted and that pdba offset may be zero when the block is empty (affected block has never formatted:block flag 0x01 or flag 0x05 and type is zero). If the block is formatted for a former dropped object, then the argument can be different than zero.
DBMS_SPACE_ADMIN.ASSM_SEGMENT_VERIFY with verify_option=>DBMS_SPACE_ADMIN.SEGMENT_VERIFY_SPECIFIC and attrib=>DBMS_SPACE_ADMIN.BITMAPS_CHECK may sometimes identify if this is a permanent inconsistency; it may be canceled when visiting the first problematic block, thus may not identify all affected blocks.