Java can be faster then plsql, it can be slower. Existing PLSQL can always be tuned to go faster as well. Do not recode all of your PLSQL in java, that would be a waste of time. The interaction between Java and PLSQL is potentially faster then the interaction between Java and a Java stored procedure (for Java to call a java stored procedure we must take java types -> turn them into sql types -> turn them into java types and do the reverse on the way out. for Java to call a plsql stored procedure we must take a java type -> turn it into a sql type and do the reverse on the way out)

My experience shows that

- if you give me a non-trivial Java stored procedure, I'll be able to write it to run in PLSQL faster.

- if you give me a non-trivial PLSQL stored procedure, I'll be able to write it to run in Java faster.

point being -- they are about the same, there are times when java will beat plsql and vice versa.

The problem is not in the execution speed of PLSQL in as much as it will be an untuned series of queries/statements in your PLSQL routine.

I suggest you look at:

o timed_statistics
o SQL_TRACE
o and especially TKPROF

and failing that, see the dbms_profiler package for source code profiling of PLSQL.

To get started with TKPROF, which will probably identify your performance bottleneck, it'll find that query(s) that is causing your slowness, see

</code> http://docs.oracle.com/cd/A81042_01/DOC/server.816/a76992/ch14_str.htm#1018

If you have problems interpreting the results of TKPROF, feel free to follow up with that.

The profiler, which should only be used AFTER your queries are running at the speed of light, can be read about here:

http://docs.oracle.com/cd/A81042_01/DOC/server.816/a76936/dbms_pro.htm#1003424 <code>

....