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:[EMAIL PROTECTED] >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: [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: Jared Still > 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: John Kanagaraj 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).
