Function of Remaining Dispatcher Parameters

The previous two lessons explained the function and configuration of the first four of seven init.ora parameters required to initialize MTS. This lesson examines the remaining three: mts_max_dispatchers, mts_servers, and mts_max_servers.

The mts_max_dispatchers parameter sets the maximum number of dispatcher processes (out of the total number of network protocols) that can be started for the duration of an instance. You can create as many dispatcher processes as you need, but the total number of processes cannot exceed the host operating system's limit on the number of running processes (normally the maxuproc UNIX parameter). To estimate the maximum number of dispatcher processes an instance will require, use the following formula:

The mts_servers parameter determines the number of shared server processes that start at instance startup. The appropriate number of shared server processes for a database system depends on how many users typically connect to it and how much processing each user requires.
If you want Oracle to use shared servers, you must set mts_servers to at least 1. If you omit the parameter or set it to 0, Oracle does not start any shared servers at all. However, you can set mts_servers subsequently to a number greater than 0 while the instance is running.

In situations where each user makes relatively few requests over a given period of time, one shared server process can serve 10 to 20 users. If each user requires a significant amount of processing, a higher ratio of server processes to user processes is needed to handle requests.
It is best to estimate only a few initial shared server processes. Additional shared servers start automatically when needed and they are shut down automatically if they remain idle. However, the initial servers always remain allocated even if they are idle. If you set the initial number of servers high, your system might incur unnecessary overhead.

The mts_max_servers parameter establishes during instance startup the maximum number of shared server processes that can be started for the duration of an instance. In general, set this parameter to allow an appropriate number of shared server processes during times of greatest activity. Whenever an instance is to be bounced, stop the listener, shut down the instance, restart the listener, and start up the instance. The listener reads the MTS parameters only if it is running before startup of the instance. Therefore, bouncing the listener without bouncing the database will disable the MTS and the listener will restart in dedicated mode.

You cannot stop and restart the listener when connecting via MTS. You must connect to Server Manager with a dedicated listener.
The next lesson discusses how to configure multiple listeners.

Before moving on to the next lesson, click the Quiz link below to check your mastery of dispatcher parameters with a multiple-choice quiz.
Shared Server Concepts - Quiz