Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: MTS

Re: MTS

From: Anton Buijs <aammbuijs_at_xs4all.nl>
Date: Tue, 28 May 2002 23:39:02 +0200
Message-ID: <ad0tbu$k2k$1@news1.xs4all.nl>


Basically it is set up with the init.ora mts% parameters. Increase shared_pool_size too because PGA memory moves from the dedicated server to the shared pool.
It's better to set a value for large_pool_size so this PGA memory is allocated in the large pool instead of the shared pool (so no need to increase the shared pool then). This prevents fragmentation of the shared pool. But it requires tuning. When the large pool is too small sessions get fatal errors. A good estimate is to query V$SESSTAT for a while and measure the values for the statistic "session pga memory" (search for the value for statistic# for your Oracle version in V$STATNAME). The average multiplied by the number of concurrent sessions and a savety margin of 25% gives you an estimate for large_pool_size. Query V$SGASTAT to see if it large enough and not to large (waste of valuable memory). Be carefull to decrease processes because you can't support dedicated servers anymore (see later, because it can happen). If you do, set an appropriate value for sessions. Normally sessions is derived from processes but in case of MTS you can have 50 processes (background, 5 dispatchers, 15 shared servers) and 500 sessions.

TNSNAMES.ORA can have influence. You can add "server = dedicated" or "server = shared" to the connect_date section (see Network manual, appendix C for the syntax) to force a type of connection. Without it it connects shared when the database has registered the dispatchers at the listener. Use "lsnrctl services" to see if they have. In V7.3 and V8.0 there is a problem that dispatchers do not register again at the listener when you stop/start the listener. The database must be started again if the listener was stopped which can be painfull. But if you don't you suddenly get only dedicated connections and you don't want that to happen (why use MTS then). That means that you must always start the listener first and then the database. Did not see this behaviour in V8.1.

V$SESSION.SERVER column shows you how the sessions are actually connected.

Views V$MTS, V$SHARED_SERVER, V$DISPATCHER give info for tuning purposes (are ther sufficient dispatchers and shared servers). V$CIRCUIT show what dispatcher is actually in a dialog with a shared server. Normally rows in v$CIRCUIT are seen for a very short time.

In my experience MTS is only usefull when there are > 100 concurrent users. Don't start more than 1,5 - 2 * #CPU's of shared servers. So when the node has 5 CPU's start 8 - 10 shared servers. Make mts_servers = mts_max_servers. 1 dispatcher can easily deal with 3 - 5 shared servers. So mts_dispatchers=3 or 5.
We found that waiting on a shared server to become available is more efficient than having too much processes fighting to get a CPU (context switches). Use "sar -q" column runocc to see how mcuh percentage of the time processes where waiting on the CPU (the runqueue). When that's to high, you have to many processes.

Also note that when a database runs MTS a very different code execution path is used in the oracle program. You can experience more bugs then in dedicated mode.

Visit http://www.ixora.com.au/ and other websites like Metalink and search for MTS.

Alain <alainthiery_at_vnumail.com> schreef in berichtnieuws 3cf3ec5b$0$247$626a54ce_at_news.free.fr...
| I dont understand where to configure MTS, in the database, in the
| listener.ora, tnsnames.ora
| and how to verify that a base support Multithread
|
| ALAIN
|
|
Received on Tue May 28 2002 - 16:39:02 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US