Re: Multi-threaded OCI Application Does Not Scale

I think you are absolutely correct - the real oddity is that multiple threads don't scale but multiple processes do.

I an rather hoping that you will see lots of 'sql*net message from client" as the
wait event when you using multiple threads as this would tend to confirm that the
problem was a failure at the front end
to handle the threading.

However it is possible that the bulk of
the wait time will be an unexpected
event like an enqueue that no-one has
previously come across.

--
Regards

Jonathan Lewis
http://www.jlcomp.demon.co.uk

Coming soon a new one-day tutorial:
Cost Based Optimisation
(see http://www.jlcomp.demon.co.uk/tutorial.html )

____UK_______March
____USA_(FL)_May


Next Seminar dates:
(see http://www.jlcomp.demon.co.uk/seminar.html )

____USA_(CA, TX)_August


The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html


Cary Lapoint wrote in message
<6b0e1783.0301240741.4e22a8e4_at_posting.google.com>...


>Interesting that the program in question does exactly what yours does

>- loads telco data (call records, I assume) into an Oracle database.

>As it happens, our tables are already partitioned - by day and

switch.


> Still, the question remains...  Why would the total import rate

>increase (until exhausting system resources) when launching

additional


>program instances but remain roughly constant or decrease slightly

>when launching additional threads from within a single process.  From

>this observation, I can completely rule out any sort of database

>bottleneck, no?  From a database perspective, the two cases are

>identical - multiple connections/sessions, each performing array

>INSERT'S of the same data into the same partitions.  If I am missing

>something, please point it out.  All the same, I will try having a

>look at V$SESSION_EVENT during program execution to see what I see.

>Thanks.

>

>Cary

>