Sergey, I think we'll need to clarify what is meant by "system overhead is reduced"...
The "code path" for a SQL statement certainly increases dramatically with MTS, in comparison to the default "dedicated server" mechanism. After all, the command from the client hits the dispatcher process, who is juggling numerous (usually a max of 30-40) session-level "user global areas" (UGAs) which all reside in the SGA. Thus, to access/modify these UGAs, there is a fair of amount of latching and other synchronization with other processes accessing the SGA, particularly if the UGAs are forced to reside in the Shared Pool because the Large Pool has not been configured. Next, the dispatcher routes specific SQL operations to the "next available" shared server process, which is a fair amount of inter-process communication and context switching. The shared server process performs the SQL operation and then must communicate the fetched data or the operation result status code(s) back to the dispatcher process -- more inter-process communication and context switching. When it is not servicing other session requests, the dispatcher process dequeues/receives the data and result codes and passes them back to the client. In contrast, a dedicated server process does all of this within one process, with the UGA and PGA all within "private" process memory (no synchronization) and no inter-process communication at every step of the way. Much simpler, much more efficient, and much much more stable. It uses more virtual memory to do this, of course... In summary, MTS is a "niche" mechanism that provides benefit only in a relatively small number of circumstances. The only benefit of MTS is the reduction of virtual memory consumption. That is all. However, everything is a tradeoff, and the tradeoff for reducing memory consumption using MTS is the considerable *increase* in processing "overhead" for each SQL operation. Not to mention the various application scenarios which can wreak havoc in multiplexing architecture like this: long-running SQL operations tying up a shared server, DBMS_LOCK.SLEEP calls tying up a shared server, various types of locks or slowly-serviced operations tying up a shared server. Each of these scenarios deny service to other sessions who might be waiting for it... All in all, it is probably not wise to consider using MTS unless you absolutely must, because you have so many connected user sessions that virtual memory has begun to page frequently and wholesale swapping is occurring. Even then, a mixed configuration of MTS and dedicated servers is advisable, with MTS handling the high numbers of relatively idle "interactive" sessions and dedicated servers handling batch programs, reports, and pooled connections from servlet-based applications. With the increasing prevalence of pooled database connections from application servers in newer OLTP applications, the need for MTS continues to decrease. It is mainly useful for old-style two-tier OLTP applications (from VB, PowerBuilder or older Oracle Forms tools) and grossly-inefficient CGI-style web-based applications... Just my $0.02... -Tim ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Wednesday, May 15, 2002 9:23 PM > Hello Eriovaldo, > > > I think you mean shared mode is multithreaded configuration. > > The multithreaded server configuration (MTS) allows many user processes to > share very few server processes. The user processes connect to a > dispatcher background process, which routes client requests to the > next available shared server process. > The advantage of the multithreaded server configuration is that system > overhead is reduced, increasing the number of users that can be > supported. A small number of shared server processes can perform the > same amount of processing as many dedicated server processes, and > the amount of memory required for each user is relatively small. > > You need to add several parameters to your init file to enable MTS: > mts_dispatchers > mts_servers > > In dedicated mode every connection has it's own server process > processing it's data. > > The advantages of MTS become valuable when there are several hundred > simultaneously connected users (at least) and it's an OLTP application > (server processes consistently wait for user input, etc. I mean server > processes load is relatively small) > > Thursday, May 16, 2002, 8:48:21 AM, you wrote: > > EA> Hi friends : > > EA> What is the diference between The instance in dedicated mode and shared mode > EA> ? > > EA> Can I to change the mode from one to other ? > > EA> What is the best way ? > > EA> Regards > > EA> Eriovaldo > > > > > > -- > Best regards, > Sergey mailto:[EMAIL PROTECTED] > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Sergey V Dolgov > INET: [EMAIL PROTECTED] > > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 > San Diego, California -- Public Internet access / Mailing Lists > -------------------------------------------------------------------- > 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.com -- Author: Tim Gorman INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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).
