Identify the Dispatcher Parameters Used with Oracle Shared Server

Oracle's Multi-Threaded Server was renamed Shared Server starting with Oracle9i, and the dispatcher based architecture this lesson covers has stayed the same one ever since. To configure Shared Server, the database's initialization parameters need to include several dispatch parameters that define how dispatcher and shared server processes handle client connections. This lesson walks through those parameters one at a time, then covers how to change them, how much shared pool memory they cost, and how to verify the configuration once it is in place.

DISPATCHERS is the single most important parameter here, and it is worth understanding its syntax in full before looking at the smaller parameters around it. Unlike most initialization parameters, DISPATCHERS is not a simple value; it is a string of parenthesized attributes describing one dispatcher configuration.

A protocol address is required, specified with one or more of these attributes:

• ADDRESS: the network protocol address of the endpoint the dispatchers listen on.
• DESCRIPTION: a fuller network description of that same endpoint, in (DESCRIPTION=(ADDRESS=...)) form.
• PROTOCOL: the network protocol itself, for example (PROTOCOL=tcp).

A second group of attributes is entirely optional and describes how many dispatchers to run and how each one behaves:

• DISPATCHERS: the initial number of dispatchers to start for this configuration. It defaults to 1 if omitted.
• CONNECTIONS: the maximum number of network connections allowed for each dispatcher.
• SESSIONS: the maximum number of network sessions allowed for each dispatcher.
• LISTENER: an alias, resolved through a naming method, for the listener the LREG background process registers this dispatcher configuration's information with.
• MULTIPLEX: enables the Oracle Connection Manager session multiplexing feature.
• SERVICE: the service name or names this set of dispatchers registers with the listener.

Any of these attribute names can be shortened to its first three characters or more, so SES=3, SESS=3, and SESSI=3 are all equivalent to writing out SESSIONS=3 in full.

A simple example, three dispatchers for the TCP protocol:

DISPATCHERS = "(PROTOCOL=TCP)(DISPATCHERS=3)"

And a fuller example naming both a specific listener and a service for those dispatchers to register:

DISPATCHERS = "(PROTOCOL=tcp)(LISTENER=listener_alias)(SERVICE=fred)"

If Shared Server is enabled by setting SHARED_SERVERS to a nonzero value, but DISPATCHERS is left unset entirely, Oracle creates one dispatcher for the TCP protocol automatically, which is equivalent to explicitly writing DISPATCHERS="(PROTOCOL=tcp)". You can also configure more than one dispatcher configuration at once, either by setting DISPATCHERS to a comma separated list of strings, or by repeating the parameter on adjacent lines in the parameter file; Oracle assigns each one an INDEX value starting at zero, which becomes useful when you want to change one specific configuration later.

The number of dispatchers you configure should be based on how many concurrent connections you expect for each network protocol, not guesswork. Once you know how many connections a single dispatcher process can support on your operating system, calculate the initial dispatcher count for each protocol with:

Number of dispatchers = CEIL( max. concurrent sessions / connections per dispatcher )

CEIL simply rounds the result up to the next whole number. For example, suppose a system supports 970 connections per dispatcher process, with a maximum of 4,000 concurrent TCP sessions and 2,500 concurrent TCP with SSL sessions expected. That works out to a minimum of five TCP dispatchers (4,000 divided by 970, rounded up) and three TCP with SSL dispatchers (2,500 divided by 970, rounded up):

DISPATCHERS='(PROT=tcp)(DISP=5)', '(PROT=tcps)(DISP=3)'

Treat this as a starting point rather than a fixed answer; depending on how the system actually performs, you may need to raise or lower the dispatcher count later using the ALTER SYSTEM statements covered next.

DISPATCHERS, like the other shared server parameters covered below, is dynamic. You do not need to restart the instance to change the number of dispatchers or their attributes; an ALTER SYSTEM statement takes effect immediately.

For example, if the instance was started with DISPATCHERS='(PROT=tcp)(DISP=2)', '(PROT=tcps)(DISP=2)', you could raise the TCP dispatcher count to 3 and lower the TCP with SSL count to 1 with either of these equivalent statements:

ALTER SYSTEM SET DISPATCHERS = '(INDEX=0)(DISP=3)', '(INDEX=1)(DISP=1)';

ALTER SYSTEM SET DISPATCHERS = '(PROT=tcp)(DISP=3)', '(PROT=tcps)(DISP=1)';

If INDEX is omitted, Oracle modifies the first existing dispatcher configuration that matches the DESCRIPTION, ADDRESS, or PROTOCOL given, or adds a new configuration if none matches. If fewer dispatchers currently exist than the new count calls for, Oracle starts new ones; if more exist than needed, Oracle terminates the extras as their connected users disconnect.

One detail worth remembering: changing DESCRIPTION, ADDRESS, PROTOCOL, CONNECTIONS, or MULTIPLEX only affects dispatchers started after the change; existing dispatchers keep their old settings until you forcibly terminate them and let new ones start in their place. The LISTENER and SERVICE attributes are not subject to this limitation and apply to existing dispatchers immediately, as does a reduced SESSIONS value; an increased SESSIONS value, like the others, only applies to newly started dispatchers.

A word on persistence: ALTER SYSTEM ... SCOPE=BOTH changes the running instance and writes the new value to the server parameter file (SPFILE) in one step, which is what most of the examples in this lesson assume. That only works, however, if the instance is actually using an SPFILE. A traditional text based PFILE, the classic init.ora file, is still fully supported; it just cannot be written to by ALTER SYSTEM. If your instance starts from a PFILE, use SCOPE=MEMORY to change a parameter for the running instance, and edit the init.ora text file by hand if you want the change to survive the next restart. Using an SPFILE is simply more convenient for this kind of ongoing administration, not a requirement.

A handful of other parameters work alongside DISPATCHERS rather than as attributes within it:

• SHARED_SERVERS: enables Shared Server and sets the initial number of shared server processes to start. Setting it to any nonzero value is what turns Shared Server on in the first place.
• MAX_SHARED_SERVERS: caps how many shared server processes can run at once, which is useful for reserving CPU and memory for other work, such as batch jobs that run overnight. Consider a telemarketing system where agents connect through Shared Server during the day: setting MAX_SHARED_SERVERS below roughly a third of the instance's total PROCESSES limit reserves the remaining capacity for dedicated connections, so nighttime batch jobs are not left waiting for shared servers to be released. It does not need to be set greater than or equal to SHARED_SERVERS; the two are independent settings.
• MAX_DISPATCHERS: caps how many dispatcher processes can run at once. In practice this parameter can largely be ignored today. It exists for a future release in which the number of dispatchers would be auto-tuned based on concurrent connections, and an administrator can already raise the number of dispatchers past this limit with ALTER SYSTEM if the workload calls for it.
• CIRCUITS: the maximum number of virtual circuits available in shared memory for inbound and outbound sessions combined, protecting shared memory from being exhausted by an unexpectedly large number of connections.
• SHARED_SERVER_SESSIONS: the maximum number of concurrent shared server user sessions. Setting this lets you reserve database sessions for dedicated server connections, so that administrative work, such as backing up or recovering the database, is never preempted by an unusually busy shared server workload.

Example values for all five:

MAX_DISPATCHERS = 10
SHARED_SERVERS = 5
MAX_SHARED_SERVERS = 20
CIRCUITS = 100
SHARED_SERVER_SESSIONS = 50

On their own, none of these parameters does very much; it is the combination that actually configures Shared Server. A small but complete parameter file entry might look like this:

SHARED_SERVERS = 5
MAX_SHARED_SERVERS = 20
DISPATCHERS = "(PROTOCOL=tcp)(DISPATCHERS=3)(SERVICE=fred)"
MAX_DISPATCHERS = 10
CIRCUITS = 100
SHARED_SERVER_SESSIONS = 50
SERVICE_NAMES = "fred"

Here, SHARED_SERVERS = 5 turns Shared Server on and starts five shared server processes; DISPATCHERS starts three TCP dispatchers registered under the fred service, matching the instance's own SERVICE_NAMES entry; and the remaining parameters set sensible ceilings and reservations around that core configuration. None of this requires a restart to apply, and none of it requires abandoning a traditional init.ora PFILE, though an SPFILE makes the day to day tuning shown in the next section considerably less error prone.

SERVICE_NAMES is not a dispatch parameter in its own right; it is the general instance parameter that lists the service name or names the instance registers with listeners. A dispatcher's own SERVICE attribute typically names one of the values already set here, so the two work together rather than duplicating each other.

SERVICE_NAMES = "mydb"

A dispatcher configuration registers with a listener through its own LISTENER attribute, the one described earlier as part of DISPATCHERS, not through the separate LISTENER_NETWORKS parameter. LISTENER_NETWORKS is a real, current parameter, but its job is different: it partitions an instance's listener registrations across multiple networks, working together with LOCAL_LISTENER and REMOTE_LISTENER, and it applies to dedicated and shared server registration alike rather than being specific to dispatchers.

Whichever listener a dispatcher registers with, every address that dispatcher listens on must also be defined in that listener's own configuration file, and you specify addresses somewhat differently depending on the network protocol in use.

At the operating system level, each dispatcher is its own process, named following Oracle's ora_d<NNN>_<SID> convention, so a process listing shows one line per dispatcher:

dilbert:[/u/oracle] > ps -ef | grep ora_d0

  oracle 19236     1   0 07:42:15      -  0:00 ora_d001_fred
  oracle 29520     1   0 07:42:15      -  0:00 ora_d000_fred
  oracle 30084 32034   1 07:47:09  pts/7  0:00 grep ora_d0
  oracle 33642     1   0 07:42:15      -  0:00 ora_d002_fred

Oracle's own V$DISPATCHER view gives you the same information from inside the database, along with the dispatcher's name and network address:

SELECT NAME, NETWORK FROM V$DISPATCHER;

Each dispatcher is uniquely identified by a name of the form Dnnn, which you can use to shut down that specific process rather than leaving the choice up to Oracle. For example, to shut down dispatcher D002:

ALTER SYSTEM SHUTDOWN IMMEDIATE 'D002';

The V$DISPATCHER view also exposes a CONF_INDX column, which tells you which dispatcher configuration, by its INDEX value, a given dispatcher belongs to; that is useful once more than one DISPATCHERS configuration is in play, such as separate configurations for TCP and TCP with SSL. To see the configuration values themselves, the number of dispatchers requested for each configuration and so on, rather than the state of the running dispatcher processes, query V$DISPATCHER_CONFIG instead; V$DISPATCHER tells you what is actually running, while V$DISPATCHER_CONFIG tells you what was asked for.

When users connect through Shared Server rather than a dedicated server, Oracle needs additional shared pool space to hold each connection's User Global Area (UGA), the session state that would otherwise sit safely inside a dedicated server's own private process memory.

If you configure a large pool, Oracle still allocates a fixed amount, about 10 KB, from the shared pool for each configured shared server session; the larger remainder of that session's UGA then comes from the large pool instead, which reduces fragmentation of the shared pool's SQL cache. If you do not configure a large pool, the entire UGA for each shared server session is allocated from the shared pool. Either way, plan to size shared_pool_size, and large_pool_size if you use one, with some headroom for the number of concurrent shared server sessions you actually expect, and adjust after observing real usage rather than committing to a number in advance.

It is worth keeping this in perspective: even though shared memory usage rises with Shared Server, total memory consumption across the instance still falls, because far fewer processes are running overall, and each of those processes needs its own share of process specific memory. Shared Server trades a larger, centralized shared pool allocation for a much smaller total footprint than an equivalent number of dedicated server connections would need.

You can check current shared pool allocation directly:

SELECT
    name,
    bytes / 1024 / 1024 AS size_in_mb
FROM
    v$sgastat
WHERE
    pool = 'shared pool';

The V$SHARED_SERVER view is worth monitoring alongside this; a simple count of shared servers that have not yet quit gives you a quick read on how many are currently running.

Once the parameters above are set, a quick check confirms Shared Server is actually configured the way you expect:

SHOW PARAMETER dispatchers
SHOW PARAMETER shared_servers
SELECT NAME, NETWORK, CONF_INDX FROM V$DISPATCHER;

The next lesson investigates the remaining dispatch parameters.