Mar 12, 2013 2:21:00 PM by Quest Software
Before implementing MTS (Multi-Threaded Server), there are several questions you need to answer:
The last item, regarding memory, can sneak up on you. When dedicated server connections are used, session-specific memory is contained in the memory area of each dedicated server process. With MTS, session-specific memory ends up in either the shared pool or the large pool. When you implement MTS, you may need to increase your pool sizes to accommodate the extra demand for memory.
You can decide this based on the protocols in use at your site. You do not need to implement MTS for every protocol that you use. If you are supporting 500 TCP/IP users and only 5 SPX users, you may find that there's no real benefit to be gained by moving those 5 SPX users to MTS. The big gain would probably come from moving those 500 TCP/IP users to MTS.
Another thing to think about here is whether or not you are supporting Common Object Request Broker Architecture (CORBA) connections to your database. CORBA is sometimes used to support object-oriented development. If you are supporting CORBA, then you'll need separate MTS_DISPATCHERS entries in your instance parameter file to define dispatchers that support the session and presentation layers used for CORBA connections.
Dispatcher processes handle the flow of requests and results between database clients and the shared server processes. At a minimum, you need to have one dispatcher for each protocol that you support. However, there are several reasons why you might want or need more than that.
One factor affecting the number of dispatchers you may need to create is your operating system's limit on the number of connections that can be made to a single process. If your operating system allows a maximum of 254 connections to one process, and you want to support 600 TCP/IP connections using MTS, then you'll need three dispatcher processes for the TCP/IP protocol. Take the number of connections that you want to support, divide that by the maximum number of connections per process, and round the result up to the next integer value. Click Here for what to do if you don't know the connection limit.
Performance is another factor affecting the number of dispatchers that you might want to have. Dispatchers need to be able to keep up with the rate at which clients make requests, and the rate at which results need to be sent back as a result of those requests. If your clients are busy, you may need to create more dispatcher processes in order to distribute the load. The later section titled "Changing the Number of Dispatchers" talks more about this issue. A reasonable course of action when you first configure MTS is to base the number of dispatchers on the number of connections that you need to handle. You can then monitor how busy they are and make adjustments later if necessary.
Two initialization parameters, MTS_SERVERS and MTS_MAX_SERVERS, allow you to specify the minimum and maximum number of shared server processes that you want to create for an instance:
When implementing MTS, you may want to provide for a limited number of dedicated server connections. Not all types of connections benefit from MTS, and some tools and operations require a dedicated connection. In particular, you need dedicated connections for the following:
Usually, the best way to provide for a dedicated connection is to create a separate net service name for that purpose. The use of MTS can be overridden in a net service name definition.
When you implement MTS, you need to have some idea of how much shared pool or large pool memory is required for use as session-specific memory. One way to do that is to look at the current amount of memory used by a representative session, and then extrapolate from that to cover the number of sessions you expect to have connected simultaneously. The query in the following example retrieves information about the amount of session memory used by the currently logged in user named GNIS:
SQL> --First, get the SID for the user named GNIS. SQL> SELECT SID 2 FROM v$session 3 WHERE username='GNIS'; SID ---------- 11 SQL> --Next, check on the GNIS user's session memory usage. SQL> SELECT sn.name, ss.value 2 FROM v$sesstat ss, v$statname sn 3 WHERE ss.statistic# = sn.statistic# 4 AND sn.name IN ('session uga memory', 'session uga memory max') 5 AND ss.sid=11; NAME VALUE ------------------------ ---------- session uga memory 51568 session uga memory max 61300
The session uga memory value represents the amount of memory that a user is currently using for session-specific purposes. The session uga memory max value represents the maximum amount of session-specific memory that has been used at any one time during the user's current session. If this user was representative of your other users, and you expected to have 500 such connections concurrently, you could multiply both values by 500 to come up with an estimated range of 25,784,000 to 30,650,000 bytes. This is the amount of additional memory that you need to allocate in the SGA for use by MTS sessions. By default, MTS uses the shared pool for session memory, but Oracle recommends the use of the large pool. By using the large pool, you avoid fragmenting the shared pool. With respect to this example, you might add the following to your instance parameter file:
LARGE_POOL_SIZE = 32M
This allocates a large pool of 32 megabytes in size, somewhat larger than the high end of our estimated range for session memory. Allocating a large pool is all you need to do in order to have Oracle use it for MTS session memory. MTS session memory comes out of the shared pool only if there is no large pool at all.
Written by Quest Software