Email: service@parnassusdata.com 7 x 24 online support!
ORA-00600 [KDDUMMY_BLKCHK] RECURRING
The exact error in that file is:
ORA-600: internal error [kddummy_blkchk], [255], [2392], [6401] the error 6401 was detected for file 255 block 2392. Block Checking: DBA = 1069549912, Block Type = KTB-managed data block *** actual free space = 2612 < kdxcoavs = 2617 ---- end index block validation rechecking block failed with error code 6401 The current sql is a parallel select, the trace file is from a pq slave. The stack trace suggests we are doing block clean out. The block dumps shows an IOT with 6 key and 3 non key columns. These are indeed all the symptoms of bug 6646613, so this situation is caused by bug 6646613. Checking the backport files: 43810, 0000, "check-and-skip corrupt blocks in index scans" The event is implemented in kdi.c and kdir.c and it sets some flags, that should cause the block to be checked and skipped if corrupt. But that scenario does not apply here, in this case we are cleaning the block, and only then the corruption visible, after the cleanout.
The problem is that the blocks are already corrupt but our code does not detect it, until the blocks are cleaned out. In general the problem is a small difference in the available free space. If the blocks are not updated any further they can still be queried and give the correct results. A further update can seriously corrupt a block as we then possibly try to put in a row for which there in reality is no space and severely thrashing the block in the process, by overwriting important structures. To salvage the data you either use DUL or clone the database and disable all events and block checking. You can then introduce corruptions but you can query the data so you can use any method to salvage the data. We advise to do this on a clone to protect you from unexpected side effects.
Refer http://parnassusdata.com/en/emergency-services for more info.