Result Set fetch agonisingly slow

Question

I am having sporadic trouble retrieving data from a ResultSet. I do not know how to tell if it is an Oracle problem or a JDBC problem.
In a while( results.next() ) loop, for some result sets it pauses for several seconds after every 10 iterations. This usually causes a webserver time-out and the results never get to the browser. It is NOT volume related, as some LARGER result sets from almost identical queries (i.e. with just one value in the where clause changed) run fine. We are using Oracle 8i, and the "problem" query always runs fine in SQLPlus (i.e. less than ten seconds for the execution and display of ~700 rows).
some relevant evidence:
a) Usually the PreparedStatement.execute() itself is pretty quick - just a few seconds at worst
b) All result sets from this query pause every 10 iterations, but most pause for just a fraction of a second
c) With a certain value in the where clause, the pauses are 4-30 seconds, which, even when only ~700 rows are returned, results in a response time of several minutes.
d) The pauses are in the results.next() statement itself (I have output timestamps at the very beginning and the very end of the loop to show this).
e) the query is a join of six tables
f) the part of the where clause that changes is: AND FULFILLER.NAME IN (...) , where the IN clause can contain single or multiple names (but I am using a single value in the "problem" query)
g) The FULFILLER.NAME column IS an indexed field, and that index IS being used (according to "EXPLAIN PLAN") in both the fast queries and the slow queries.
What confuses me (amongst several things) is this: I would have thought that the values in the where clause would only affect the creation of the ResultSet, and not the reading of that result set. Am I wrong? Any ideas anyone?
Thanks,
Martin Reynolds (renozu)

Answer 1

I am having sporadic trouble retrieving data from a
ResultSet. I do not know how to tell if it is an
Oracle problem or a JDBC problem.
In a while( results.next() ) loop, for some
result sets it pauses for several seconds after every
10 iterations. This usually causes a webserver
time-out and the results never get to the browser. It
is NOT volume related, as some LARGER result sets from
almost identical queries (i.e. with just one value in
the where clause changed) run fine. We are using
Oracle 8i, and the "problem" query always runs fine in
SQLPlus (i.e. less than ten seconds for the execution
and display of ~700 rows).
some relevant evidence:
a) Usually the PreparedStatement.execute() itself is
pretty quick - just a few seconds at worst
b) All result sets from this query pause every
10 iterations, but most pause for just a fraction of a
second
c) With a certain value in the where clause, the
pauses are 4-30 seconds, which, even when only ~700
rows are returned, results in a response time of
several minutes.
d) The pauses are in the results.next() statement
itself (I have output timestamps at the very beginning
and the very end of the loop to show this).
e) the query is a join of six tables
f) the part of the where clause that changes is:
AND FULFILLER.NAME IN (...) , where the IN
clause can contain single or multiple names (but I am
using a single value in the "problem" query)
g) The FULFILLER.NAME column IS an indexed field, and
that index IS being used (according to "EXPLAIN PLAN")
in both the fast queries and the slow queries.
What confuses me (amongst several things) is this: I
would have thought that the values in the where clause
would only affect the creation of the
ResultSet, and not the reading of that result
set. Am I wrong? Any ideas anyone?
this honestly doesn't HAVE to be the case... depending on the cursor.
i think if one has a forward only cursor the database could figure it out as it scans along the table. it should be fater in fact because if it does like this you only do one table scan and not two. this theory seems to fall apart when you say it is using the index BUT if I was writing a database and you had a forward only cursor AND the distribution of keys in the index indicated that there were many rows that would match your query I might ignore the index and do it as described.
so call me crazy but here is my suggestion...
if the cursor you are using is a forward only cursor then try a scrollable cursor.
if it is already a scrollable cursor or changing it didn't help then try this...
rs.last();
rs.beforeFirst();
// now process normally using next()i would think that this would force the database to find all the rows.... so it should help.
also the server timeout issue will sort of need to be addressed also if the query still takes a long time to run...
Thanks,
Martin Reynolds (renozu)