OAF Update of Custom Table causing ORA-600 with database block corruption?

Question

Using OA Framework 12.1.3, running under EBusiness Suite 12.1.3
Created Custom Web page operating against Custom Tables
ISSUE
On about 2% of new records, when OAF is UPDATING a record in a certain table, it  is failing with
java.sql.SQLException: ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [kddummy_blkchk], [815], [26412], [6110], [], [], [], []
ORA-06512: at line 1
Before the DBA turned on 10.2.0.4.0 DB_BLOCK_CHECKING parameter, this actually
resulted in corrupted data blocks in the database and corrupted indexes that
eventually crashed the database and we had to do a full recovery with 2 days downtime.
Now that we have turned on DB_BLOCK_CHECKING, it simply errors out and puts things
in the alert log, but the records still fail to update as the writes are blocked.
Then oddly, a few days later.. the records become editable.  And others fail.
This is ONLY happening on the one particular table being updated by OAF.  Other custom pages
posting to other custom tables are having no problems.   We've CTAS'd the table back and
forth and recreated the indexes, and that did not help.
Support says to post to the Forum  ( So I am! ) or hire Oracle consulting.. which doesn't make
much sense given the error.  The Recovery Team that helped us in a separate SR ( we had
to do db_repairs not just recovery ) felt it was an important problem the OAF team needed to
strongly review.
Anyone else encounter this already and know of a solution?
TIA
Karl

Answer 1

After MANY hours of trial and error and research, we've identified ONE use case that seems to apply to 90% of the issue we have encountered.
YMMV.
The BC4J generated SQL which is generating the ORA-600 is
BEGIN UPDATE XXRETURNHEADER ReturnHeaderEO SET INTERNAL_TEXT=?,LAST_MOD_USERNAME=?,OBJECT_VERSION_NUMBER=?,LAST_UPDATE_DATE=?,LAST_UPDATED_BY=?,LAST_UPDATE_LOGIN=? WHERE RMA_NUMBER=? AND ORGANIZATION_ID=? RETURNING TROUBLESHOOT_DATE, FAA_TAG_DATE, FAILURE_ANALYSIS_DATE, LAST_MOD_DATE, FAA_REVISED_DATE, TTE_TECH_SEND_DATE, TTE_REP_RESPONSE_DATE, TTE_REP_APPROVED, TTE_RMA_RANDOM_KEY, OBJECT_VERSION_NUMBER, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN INTO ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?; END;".
We determined that if TTE_RMA_RANDOM_KEY was not a null value, we would get an ORA-600 error whenever we did an APPLY from the OAF Page to update the record.
If we set that table attribute to NULL for the record using SQL.. then used the  OAF Page to APPLY.. it worked fine and the record saved without error.
We then modified the EO to NOT   "Refresh After Update"  ( thus removing it from the RETURNING clause generated )... and even if the TTE_RMA_RANDOM_KEY
had a value... the OAF Page APPLY worked and the record saved without error.
I cannot identify anything from the User programming side that is wrong ( and neither could Oracle ), and it REALLY should be in the RETURNING clause list of
attributes.. but this is the only workaround I've found that doesn't crash the Page and irritate the user to no end.
I have reported my findings via the SR back to Oracle to do with it what they may... but it looks strongly ,to me, to be an error in the BC4J/JDBC/Database
coordination and passing data between those black boxes.