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: John Kanagaraj
INET: john.kanagaraj_at_hds.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).
Received on Tue Nov 11 2003 - 10:49:25 CST
