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 the Oracle Shared Server. This lesson examines the remaining three:
In Oracle 11g R2, the Multi-Threaded Server (MTS) parameters were renamed to reflect their role in the shared server architecture. The equivalent parameters are:

1. mts_max_dispatchers → max_dispatchers
   Controls the maximum number of dispatcher processes that can be created.
2. mts_servers → shared_servers
   Specifies the number of shared server processes to be created when the instance starts. This parameter sets the baseline number of shared servers.
3. mts_max_servers → max_shared_servers
   Defines the maximum number of shared server processes that can be dynamically created by the Oracle instance.

These updated names better align with Oracle's shared server architecture and maintain consistency across Oracle database versions.

• max_dispatchers sets the maximum number of dispatcher processes that can be started for the duration of an instance. This ensures a limit on the total number of dispatchers, regardless of the number of network protocols in use.
• The ability to create dispatcher processes is constrained by both the `max_dispatchers` parameter and the **host operating system's limits on the total number of processes. For UNIX-based systems, this is typically governed by the `maxuproc` parameter (or an equivalent, depending on the specific flavor of UNIX/Linux).

To estimate the maximum number of dispatcher processes an instance will require, use the following formula:

MAX_DISPATCHERS

=

maximum number of concurrent sessions connections per dispatcher

• Number of Shared Server Processes The shared_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 shared_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 shared_servers subsequently to a number greater than 0 while the instance is running.

Best practices in Oracle's shared server architecture. Here is a breakdown:

1. Shared Server Utilization:
   • In scenarios where user requests are infrequent or lightweight, a single shared server process can handle multiple user sessions effectively, typically serving 10 to 20 users per shared server process.
   • For scenarios with high processing demands per user, a lower user-to-server ratio is required to maintain performance. This means more shared server processes need to be available to handle the load.
2. Dynamic Adjustment of Shared Servers:
   • Oracle dynamically manages the number of shared server processes:
   • Additional shared servers are started automatically when demand increases.
   • If shared server processes remain idle for an extended period, they are shut down automatically to conserve system resources.
3. Initial Shared Server Processes (shared_servers):
   • The number of shared server processes specified in the shared_servers parameter are always allocated at instance startup, even if idle. This ensures baseline capacity for user requests.
   • Setting this value too high can result in unnecessary overhead, such as higher memory usage and resource contention, particularly in low-demand situations.

Recommendation: Start with a "conservative number of shared server processes" and let Oracle's dynamic behavior manage scaling based on workload. Monitor and adjust if necessary, ensuring performance is optimized without excessive resource consumption.

• Maximum number of shared server processes
  The `max_shared_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 to handle the workload during peak activity. Ensure the listener is running before starting the instance, as the listener reads the shared server configuration parameters during the instance startup process. If changes are made to the listener or shared server configuration, they can often be applied dynamically without requiring a database restart. In scenarios where the database instance must be restarted (bounced), restart the listener before starting the database instance to ensure shared server connections are configured properly. To perform administrative tasks, connect using a dedicated server connection by specifying `(SERVER=DEDICATED)` in the connection string to ensure exclusive access to the instance.
  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