Mladen,
I've found MTS to be a blessing and a curse at the same time no matter what
language (C, ASP, JAVA, etc...) is being used. The biggest problem with MTS is the
number of idle shared servers that you have at any point in time. When you connection
request is processed by the database server any statements that need execution land in
the shared pool's request queue. If you have say 100 connections on the database with
10 shared servers it only takes a 10% population of active users to exhaust your pool.
Yes Oracle will start additional servers up to MTS_MAX_SERVERS but don't expect it to
respond rapidly. More like a snail that a rocket. You've got two options that I can
safely recommend:
1) configure MTS_MAX_SERVERS = MTS_MIN_SERVERS = the maximum number of
anticipated connections.
2) configure MTS_MAX_SERVERS = 2X MTS_MIN_SERVERS = 75% of the maximum number
of anticipated connections
Option 3 is more fluid, but also takes more effort to maintain the desired
performance. It means programming a process or job that will occasionally wake up,
evaluate the load on the database's shared server population & alter the mts_servers
setting of the database dynamically. It can be done, I do it, and is very successful.
Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA
-----Original Message-----
Sent: Monday, June 16, 2003 11:25 PM
To: Multiple recipients of list ORACLE-L
I'm not a Java expert so please forgive me my ignorance. JDBC application
is facing very strange performance problems during connect. Every now and then
everything appears to be hung and then, 10 minutes later, users proceed
normally but with the elevated blood pressure and serious lack of patience.
I was told that JDBC has it's own connection pooling mechanism and that it
will start it's own dedicated server connection. It seems though that the
string "SRVR=DEDICATED" has been ignored and that users are acquiring a shared
server connection.
Does anybody in this group have any experience with JDBC and MTS? Version is
8.1.7.1, 64 bit on HP-UX 11 with OPS. Dispatchers are cross-registered with
listeners on all 4 nodes for load balancing purposes. I found surprisingly
little material on the Metalink. No network collisions, no retransmits, no
timeouts can be seen from netstat -i and netstat -s. The NIC is 1GB Ethernet
and I would be very surprised if approximately 100 users could kill it with a
JDBC application. They could use DBA as a human sacrifice, though.
--
Mladen Gogala
Oracle DBA
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Mladen Gogala
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Goulet, Dick
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
