RE: interpret v$mts

From: Barbara Baker <barbarabbaker_at_yahoo.com>
Date: Wed, 2 Jun 2004 08:56:07 -0700 (PDT)
Message-ID: <20040602155607.6539.qmail@web50607.mail.yahoo.com>

Tom wrote:
all of the application software vendors
> now provide connection

Well, not our vendor.
They wrote this thing so that each user has between 6 and 10 connections each to the database. So I'm supporting 1000 db user connections for a system designed to support about 100 users.

I don't see a way to support this without MTS.

I'm still trying to understand the spike -- an add'l 33 servers started in 30 minutes. I assume that we had a flood of connections to the database in a very short period of time. I thought I could grab some info by setting auditing (audit create session by access whenever successful). But apparently mts shows a new session in audit each time it connects to a shared server to run something. Within 1 hour, I showed a user connected 314 times. Thought I was onto something, but it's just bad data.

I've opened 2 tars with oracle about the performance problems, sent RDA's, statspack, config info, etc. etc. I'm pretty much back at square one.

Thanks for listening to me whine.

Barb

"Mercadante, Thomas F" <thomas.mercadante_at_labor.state.ny.us> wrote:
> Really, the need for MTS is going away. It was
> designed for connection
> pooling, but all of the application software vendors
> now provide connection
> pooling with the app server. And it does it better
> than MTS ever did.
>
> Given a choice, I always choose app-server
> connection pooling over MTS. It
> is just too hard to tune.
>
> Tom Mercadante
> Oracle Certified Professional
>
>

Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.

--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Received on Wed Jun 02 2004 - 10:52:58 CDT