Configure init.ora Parameters Governing Shared Server

Shared Server (formerly Multi-Threaded Server, or MTS, renamed in Oracle 9i) lets many clients share a small pool of server processes. In Oracle AI Database 26ai it is controlled by initialization parameters, set either in the SPFILE, in a text init.ora parameter file (PFILE), or dynamically on a running instance with ALTER SYSTEM. With an SPFILE, ALTER SYSTEM ... SCOPE=BOTH changes the running instance and persists the change; with a text parameter file, edit the file as well so the setting survives a restart. The PFILE is still fully supported and not deprecated; it is simply less convenient for ongoing administration than the SPFILE, which keeps ALTER SYSTEM changes without manual file editing.

Shared Server is enabled by setting SHARED_SERVERS to a value greater than 0, either at startup in the parameter file or dynamically with ALTER SYSTEM. It is also enabled at startup if DISPATCHERS specifies at least one dispatcher, in which case SHARED_SERVERS defaults to 1. Because Shared Server needs at least one dispatcher to work, one is started automatically for TCP if you have not configured any.
One rule catches people out: if neither SHARED_SERVERS nor DISPATCHERS is in the parameter file at startup, you cannot start Shared Server later by altering only DISPATCHERS. You must set SHARED_SERVERS to a nonzero value. And a database created with DBCA usually already has a dispatcher for Oracle XML DB, which sets SHARED_SERVERS to 1 but lets only XDB sessions use Shared Server, as covered in the previous lesson.

Parameter	What it controls	Notes
SHARED_SERVERS	Initial and minimum number of shared servers	The only required parameter. 0 means off. Setting it to 0 disables Shared Server.
MAX_SHARED_SERVERS	Maximum number of shared servers PMON creates automatically	No default. SHARED_SERVERS overrides it.
DISPATCHERS	Dispatcher configuration, one entry per protocol or endpoint	Minimum useful value: (PROTOCOL=tcp). Has its own attributes, listed below.
MAX_DISPATCHERS	Maximum number of dispatchers	Oracle says it can be ignored for now; it is intended for a future release that auto-tunes dispatchers.
SHARED_SERVER_SESSIONS	Maximum number of concurrent shared server sessions	No default. Lets you reserve sessions for dedicated servers.
CIRCUITS	Maximum number of virtual circuits in shared memory	No default. Protects shared memory.

SHARED_SERVERS, MAX_SHARED_SERVERS, SHARED_SERVER_SESSIONS, and DISPATCHERS can all be changed with ALTER SYSTEM on a running instance. Check the Oracle Database Reference for the modifiability of the others before planning a change.

# ----------------------
# Shared Server
# ----------------------
SHARED_SERVERS = 10
MAX_SHARED_SERVERS = 50
DISPATCHERS = "(PROTOCOL=tcp)(DISPATCHERS=3)"
SHARED_SERVER_SESSIONS = 200

1. SHARED_SERVERS = 10 starts ten shared servers and keeps at least that many running.
2. MAX_SHARED_SERVERS = 50 lets PMON add shared servers under load, up to fifty. Because it is higher than SHARED_SERVERS, the number can grow and shrink with demand.
3. DISPATCHERS = "(PROTOCOL=tcp)(DISPATCHERS=3)" starts three TCP dispatchers. If you omit the parameter while Shared Server is on, Oracle starts one.
4. SHARED_SERVER_SESSIONS = 200 caps shared server sessions at 200, leaving the rest of SESSIONS for dedicated connections.

Listener registration is normally automatic through LREG. Use the LISTENER attribute of DISPATCHERS, or LOCAL_LISTENER, only when the dispatchers should register with a nondefault listener.

Shared servers. SHARED_SERVERS is the minimum, and after startup Oracle adjusts the actual number according to how busy the existing servers are and how long the request queue is. In typical systems the number settles at about one shared server for every ten connections; it runs lower when requests are heavy and higher connection-to-server ratios suit mostly idle OLTP users. PMON cannot terminate shared servers below SHARED_SERVERS, so setting it near your average load stops PMON from repeatedly ending and restarting servers as load fluctuates.

Oracle's own example is a telemarketing center with 1,000 agents who spend about 90 percent of their time on the phone. The DBA sets SHARED_SERVERS to 100. At night only 200 agents work, so the DBA lowers it to 20, freeing resources for batch jobs. Because the parameter is dynamic, no restart is needed.

Limiting shared servers. With no MAX_SHARED_SERVERS, PMON starts as many servers as the load requires, bounded by PROCESSES, a minimum of free process slots, and system resources. Set a maximum to reserve memory and CPU for other work; in the same example, the DBA keeps it below a third of PROCESSES so night batch jobs can still get dedicated servers. Remember that SHARED_SERVERS wins any conflict: setting it above MAX_SHARED_SERVERS forces more servers than the maximum, and the count then stays fixed rather than self-tuning.

Dispatchers. The number of dispatchers does not adjust itself. Estimate it per protocol with:

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

For a platform that supports 970 connections per process, 4,000 concurrent TCP sessions need five dispatchers and 2,500 TCP-with-SSL sessions need three:

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

Then adjust from what the dispatcher views show under real load.

Sessions and circuits. Set SHARED_SERVER_SESSIONS when you want to guarantee room for dedicated connections, so that tasks that require them, such as backup and recovery, are never crowded out by shared sessions. CIRCUITS caps virtual circuits and so protects shared memory; without it, circuits are limited only by the dispatcher configuration and system resources.

A protocol address is required, given through PROTOCOL, ADDRESS, or DESCRIPTION. The rest are optional. Attribute names can be shortened to their first three characters, so SESSIONS=3 and SES=3 mean the same thing.

Attribute	Purpose
PROTOCOL	Network protocol the dispatcher listens on, for example (PROTOCOL=tcp)
ADDRESS	Protocol address of the endpoint, useful for fixing a host or port, for example behind a firewall
DESCRIPTION	Full network description of the endpoint, including its address
DISPATCHERS	Initial number of dispatchers for this configuration; defaults to 1
CONNECTIONS	Maximum network connections per dispatcher
SESSIONS	Maximum network sessions per dispatcher
LISTENER	Alias of the listeners with which LREG registers this dispatcher
MULTIPLEX	Enables Oracle Connection Manager session multiplexing
SERVICE	Service names the dispatchers register with the listeners

You can specify DISPATCHERS several times, or as a comma-separated list. If you repeat the parameter in a file, the lines must be adjacent. Oracle numbers each configuration from zero with an INDEX value that you can use later in ALTER SYSTEM. Two examples that fix the address a dispatcher listens on:

DISPATCHERS="(ADDRESS=(PROTOCOL=TCP)(HOST=144.25.16.201))(DISPATCHERS=2)"
DISPATCHERS="(ADDRESS=(PROTOCOL=TCP)(PORT=5000))"

Start or resize shared servers and dispatchers without restarting:

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

The last two statements are equivalent ways of setting three TCP dispatchers and one TCP-with-SSL dispatcher; the second identifies each configuration by its index. A few behaviors are worth knowing before you rely on this:

• Reducing the number of dispatchers is not immediate. As users disconnect, Oracle ends dispatchers down to the new limit.
• Changing DESCRIPTION, ADDRESS, PROTOCOL, CONNECTIONS, or MULTIPLEX affects only dispatchers started afterward. To apply it to existing ones, end them after altering the parameter and let the database start replacements.
• LISTENER and SERVICE apply to existing dispatchers, and SESSIONS applies to them only if the value is reduced.
• To end one dispatcher, find its name in V$DISPATCHER and shut it down explicitly. IMMEDIATE drops its existing connections; without it, the dispatcher waits for its users to disconnect.

SELECT NAME, NETWORK FROM V$DISPATCHER;
ALTER SYSTEM SHUTDOWN IMMEDIATE 'D002';

Turning Shared Server off. Set SHARED_SERVERS to 0. No new client can connect in shared mode, though Oracle keeps some shared servers, the smaller of the previous SHARED_SERVERS value and MAX_SHARED_SERVERS, until existing shared connections close. If both are 0, remaining shared clients' requests queue until one is raised again. To end the dispatchers once shared clients have gone, clear the parameter:

ALTER SYSTEM SET SHARED_SERVERS = 0;
ALTER SYSTEM SET DISPATCHERS = '';

Every shared session keeps its user global area in the SGA, in the shared pool or the large pool. For installations with few sessions the defaults are usually enough; if you expect many, tune those pools deliberately, since undersized memory shows up as shared server contention. Each connection also uses a virtual circuit in shared memory, which is what CIRCUITS caps.

In a container database, configure Shared Server at the root. A pluggable database can set SHARED_SERVERS to 0 to stop using shared servers, or run ALTER SYSTEM RESET SHARED_SERVERS to go back to the root's behavior. It cannot set a nonzero value of its own.

Confirm what is configured and what is running with the Shared Server views: V$DISPATCHER_CONFIG for the dispatcher configurations, V$DISPATCHER for the running dispatchers (its CONF_INDX column shows which configuration each belongs to), V$SHARED_SERVER for the shared servers, and V$QUEUE for queue activity. If the dispatchers show consistently high load, add dispatchers; if the shared servers stay idle, lower SHARED_SERVERS.