Java – Preparedstatement and Oracle 10g bug

When we call some SQL in the Java Web application, I have a big but intermittent problem with errors in Oracle 10g. We can't quickly patch or upgrade to 11g - this seems to be the first 'stupid' Oracle support response There's a workaround, but I'm having trouble doing this in preparedstatements in Java code

The actual error is:

ORA-00600: internal error code,arguments: [kcblasm_1]

The error is: Oracle bug 12419392

Work is in progress

alter session set "_hash_join_enabled" = FALSE;

Before we run our error - inducing SQL Traditionally, however, Preparedstatement requires only one SQL:

PreparedStatement stmt = con.prepareSelect("sql statement2");

Can there be a Preparedstatement call that looks like this:

PreparedStatement stmt = con.prepareSelect("sql statement1; sql statement2;");

Or do you just do this by running a series of consecutive preparedstatements one by one?

It's not the best time to approach Xmas and reduce support, so I really hope someone can help thank you.

Edit: @ jonealles requires code, so here is, if there is any use It may be very specific to our project, but someone may find obvious error induction problems:

SELECT DISTINCT qm.validator_id,qm.QM_ID,u.EMAIL,qm.creation_dt,qm.emailed,qm.valid,qm.resolved,qm.new_obs_id,o.*,nests.*,s.*,l.*,latc.TENKM
FROM query_man qm,obs o,obs_aux_aon nests,sub s,location l,l_atlas_teTrad_coverage latc,users u
WHERE qm.OBS_ID         = o.OBS_ID
AND o.SUB_ID            = s.SUB_ID
AND u.user_id           = qm.user_id
AND o.obs_id            = nests.obs_id(+)
AND s.LOC_ID            = l.LOC_ID
AND latc.ATLAS_REGION   = 'NKNE'
AND (LENGTH (l.gridref) = 6
AND (SUBSTR(l.gridref,1,3)
  || SUBSTR(l.gridref,5,1)) = latc.TENKM
OR LENGTH (l.gridref)       = 4
AND l.gridref               = latc.TENKM)
AND qm.RESOLVED            IS NULL
ORDER BY latc.tenkm,l.teTrad

Solution

OK The answer to my main question is No. you cannot create Preparedstatement like this:

PreparedStatement stmt = con.prepareSelect("sql statement1; sql statement2;");

Running a single statement to temporarily change the session to get a little SQL does work, but consent seems bad and the response speed is unacceptably slow The options appear to be patches or upgrades, or view No_ use_ Hash hint (I think it will also be very slow) Look at the code