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

No, thanks for helping bust the myth. Iım always so surprised by the gap between what I thought I said and what I apparently communicated... :-)

Still, it is an interesting distinction. A separate TNS listener certainly isnıt required, but one of the two major scenarios that frequently call for MTS/SS (extremely frequent connect requests) might also benefit from multiple TNS Listeners or even listener load-balancing. I guess that is one reason that server-side listener load-balancing involves MTS/SS in the first place. Imagine that!

Thanks again!

on 11/11/03 11:59 AM, Jared.Still_at_radisys.com at Jared.Still_at_radisys.com wrote:

>
> Thanks John, this is the way I have done it in the past.
>
> Tim, thanks for your clarification. Thought that was more or less what
> you meant, just wanted didn't want to see any myths started stating
> that MTS requires its own listener. ;)
>
> Jared
>
>
>
>
> John Kanagaraj <john.kanagaraj_at_hds.com>
> Sent by: ml-errors_at_fatcity.com 11/11/2003 08:49 AM
> Please respond to ORACLE-L
>
> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> cc:
> Subject: RE: Multi-threaded server - will it help in this case
>
>
> Jared,
>
> I don't think that is what Tim meant. You can use something akin to the
> following:
>
> For an MTS connection/client:
>
> MYDB_MTS.MYCOMPANY.COM = (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)
> (HOST=MYHOST.MYCOMPANY.COM)(PORT=7505))(CONNECT_DATA=(SID=MYSID)))
>
> For a dedicated connection/client:
>
> MYDB_DEDICATED.MYCOMPANY.COM = (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)
> (HOST=MYHOST.MYCOMPANY.COM)(PORT=7505))(CONNECT_DATA=(SID=MYSID)(SERVER=DEDI
> CATED)))
>
> The only difference is in the TNS handles and the entry they point to which
> differs in content. The SERVER=DEDICATED will bypass the MTS configured
> default connection.
>
> You can do this via ONAMES too (and I know you use one!) - see
> Note:1036577.6. Btw, I am currently in the UK helping with a Name Server
> rollout..
>
> John Kanagaraj
> DB Soft Inc
> Phone: 408-970-7002 (W)
>
> Grace - Getting something we do NOT deserve
> Mercy - NOT getting something we DO deserve
> Click on 'http://www.needhim.org' for Grace and Mercy that is freely
> available!
>
> ** The opinions and facts contained in this message are entirely mine and do
> not reflect those of my employer or customers **

>> >-----Original Message-----
>> >From: Jared Still [mailto:jkstill_at_cybcon.com]
>> >Sent: Tuesday, November 11, 2003 7:29 AM
>> >To: Multiple recipients of list ORACLE-L
>> >Subject: Re: Multi-threaded server - will it help in this case
>> >
>> >
>> >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).