Re: Multi-threaded server - will it help in this case

Nope. They can use the same listener and I'm pretty sure they can even use the same port, but if you did the latter, you'd just want to differentiate in the TNSNAMES definition with the "(SERVER=SHARED)" or "(SERVER=DEDICATED)" clause. However, I haven't done this last thing lately and as I write, I'm not completely certain that it works and I'm not interested enough to test it out... :-)

However, I _was_ implying that it would be _easier_ to separate the different traffic to different ports, just to be a little more certain that you are getting what you are looking for when you connect. You can always check after the fact using:

   select server from v$session where audsid = userenv('SESSIONID')

Of course, if your reason for using MTS involves extremely frequent/rapid connection attempts (that cannot be corrected by fixing the application), then dedicating a separate TNS Listener to that traffic might be the better part of discretion. Old CGI-style web applications, where each click spawned a new shell process with a new connection to the database, are a prime example. Switching from CGI to modern app-servers with pooled servlet connections fixes that problem. Weirdo CAE apps that treat database connections like cursors are another problem... :-)

> Tim,
>
> This bit:
>
> > accomodate this application. Please be aware that you
> > can mix dedicated and MTS by setting up different TNS
> > names on different ports for each, so it is not an
> all-or-nothing
> seems to imply that MTS and Dedicated will each require
> their own listener ( different ports). Been awhile since
> I messed with MTS, but I don't recall that as being
> necessary.
> Is that what you meant?
>
> Jared
>
>
>
> On Tue, 2003-11-11 at 07:04, Tim Gorman wrote:
> > Peter,
> >
> > MTS (or SS in 9i onwards) is an excellent choice to
> > accomodate this application. Please be aware that you
> > can mix dedicated and MTS by setting up different TNS
> > names on different ports for each, so it is not an
> > all-or-nothing situation. Most connections to the
> > database outside of this CAE app will likely be better
> > served with dedicated connections, so just dole out TNS
> > names accordingly.
> > Also, please be sure to estimate the size of your UGA by
> > tracking values (i.e. name like '%uga%') in V$SESSTAT at
> > peak periods then sizing the Large Pool to accomodate,
> > before you enable MTS. Unless you're really constrained
> > for memory, don't be shy about this; double the highest
> > value you sum from V$SESSSTAT to be safe. After
> > enabling MTS, monitor the value of "free memory" where
> > POOL = 'large pool' in V$SGASTAT. If you've oversized,
> > you can start backing down on LARGE_POOL_SIZE gently, if
> > you need the memory elsewhere...
> >
> > Hope this helps...
> >
> > -Tim
> >
> > > Environment: AIX 4.3
> > > Oracle 8.1.7
> > >
> > > The application is a CAE tool which stores metadata
> > > for a hierarchy of 3D engineering design models.
> > > When a user opens a model at a given level in the
> > > design, the application retrieves data about that
> > > model and all of the models below it in the design
> > > try. This often involves as many as 100 or more
> > > models. Unfortunately, the way the application is
> > > written, it opens a new connection to the database for
> > > each model. Thus, in the process of retrieving
> > > metadata, it may open and close as many as 100
> > > connections to the database. Obviously, this causes
> > > some performance problems, especially for remote
> > > users. The number of users when the system goes fully
> > > into production is going to be in the low 100's.
> > >
> > > The vendor is not interested in changing the way the
> > > software works.
> > > Will use of the mult-threaded server improve
> > > performance in this situation, for
> > > example, by eliminating the overhead of starting a
> > > dedicated server for each connection?
> > >
> > > Thanks,
> > > Peter Schauss
> > --
> > Please see the official ORACLE-L FAQ:
> > http://www.orafaq.net --
> > Author: Tim Gorman
> > INET: tim_at_sagelogix.com
> >
> > 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: ListGuru_at_fatcity.com (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: Jared Still
> INET: jkstill_at_cybcon.com
>
> 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: ListGuru_at_fatcity.com (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: Tim Gorman
  INET: tim_at_sagelogix.com

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: ListGuru_at_fatcity.com (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).