Function of Remaining Dispatcher Parameters

Lessons 2 and 3 covered DISPATCHERS, MAX_DISPATCHERS, SHARED_SERVERS, MAX_SHARED_SERVERS, CIRCUITS, and SHARED_SERVER_SESSIONS, along with the MTS_* names they replaced after Oracle9i. This lesson does not reintroduce that syntax. Instead, it explains something those two lessons left out: how Oracle actually decides how many shared servers to run at any given moment, what that means for sizing SHARED_SERVERS and MAX_SHARED_SERVERS in practice, and a few operational details, listener startup order and dedicated connections for administrative work, that tie the whole configuration together.

Unlike dispatchers, shared servers are not fixed once at startup and then left alone. PMON, the process monitor background process, starts additional shared servers automatically, up to the MAX_SHARED_SERVERS limit, as load on the common request queue warrants it, and marks idle shared servers for termination once the count drops back toward the SHARED_SERVERS floor.

As a starting point for sizing, current Oracle guidance is that shared servers typically stabilize at a ratio of about one shared server for every ten client connections. That ratio is not fixed, and the reason why is fairly intuitive once you think about what a shared server actually spends its time doing. A lightweight, intermittent request occupies a shared server only briefly before that server goes back to the common queue for the next request, so one server can effectively stand behind many idle-most-of-the-time connections. A request that demands heavy processing keeps its shared server busy for longer, so fewer connections can share that same server before requests start backing up. For OLTP workloads with light, intermittent requests, a higher ratio of connections per server works fine; for workloads with heavier per-request processing, you need more shared servers per connection to keep performance acceptable.

Whatever ratio you start from, treat it as a hypothesis to check rather than a number to set once and forget. A quick count of shared servers that have not yet quit tells you how many are actually running at a given moment:

SELECT COUNT(*) "Shared Server Processes"
FROM v$shared_server
WHERE status != 'QUIT';

Watched alongside the V$QUEUE wait times covered in Lesson 3, this tells you whether the count PMON has settled on is actually keeping up with demand, or whether SHARED_SERVERS and MAX_SHARED_SERVERS need adjusting.

A concrete scenario makes this tradeoff easier to reason about. Imagine a telemarketing center staffed by 1,000 agents, each spending about 90% of their time talking to customers and only 10% of their time actually touching the database. Setting SHARED_SERVERS too low here would mean constantly terminating and respawning shared servers as agents alternate between calls and database access, wasting resources on process churn rather than saving them. So the center's DBA sets SHARED_SERVERS to 100, roughly in line with the one-in-ten ratio, to keep a stable pool available throughout the day.

Overnight, when only 200 agents are working, that same DBA dynamically lowers SHARED_SERVERS to 20, freeing resources for batch jobs that run better with fewer shared servers competing for CPU and memory. Since SHARED_SERVERS is a dynamic parameter, this change takes effect immediately with a single ALTER SYSTEM statement, no restart, and no need to wait for the night shift to log off first.

The same reasoning scales down just as easily. A small internal application with 30 lightweight, intermittent users might comfortably run with SHARED_SERVERS set to 3 or 4, following the same ratio, rather than needing anything close to the telemarketing center's numbers.

MAX_SHARED_SERVERS has no default value. If you do not set it, PMON will start as many shared servers as the load demands, limited only by the PROCESSES initialization parameter, a reserved minimum of free process slots (one eighth of the total, or two slots if PROCESSES is set below 24), and general system resources. Setting MAX_SHARED_SERVERS explicitly is mainly about reserving capacity for other work, batch jobs being the classic example, rather than about correctness; an instance with no MAX_SHARED_SERVERS set at all is not misconfigured, just unconstrained.

One detail worth remembering from Lesson 2: SHARED_SERVERS overrides MAX_SHARED_SERVERS, not the other way around. If MAX_SHARED_SERVERS is set to 20 and you then set SHARED_SERVERS to 30, PMON starts 30 shared servers regardless of the lower ceiling; the ceiling only constrains how high PMON will grow the pool dynamically in response to load, not the floor you explicitly ask for. If you want 30 to become the new ceiling going forward as well, raise MAX_SHARED_SERVERS to match.

Reserving resources for other work is not the only reason to set a ceiling. MAX_SHARED_SERVERS is also a useful tool for testing, debugging, and performance analysis: to find out how many shared servers a particular user community actually needs, you can start with a deliberately low MAX_SHARED_SERVERS and raise it step by step until users stop noticing any delay in response time. That gives you an empirically grounded number for the ceiling, rather than one guessed from a ratio alone.

It is worth being precise here, since the two are easy to conflate: the concurrent-sessions-over-connections-per-dispatcher formula covered in Lesson 2 tells you how many dispatchers to actually configure, the DISPATCHERS count attribute, not how to set MAX_DISPATCHERS. MAX_DISPATCHERS is a ceiling sitting on top of that number, and as covered in Lesson 2, one that can largely be left alone today; it exists for a future auto-tuning feature and can already be exceeded with ALTER SYSTEM if needed.

The number of dispatcher and shared server processes an instance can actually run is also bounded by the host operating system's own limit on total processes, separately from anything Oracle enforces. The specific parameter or command for checking this varies by platform; on Linux, ulimit -u for the oracle operating system user is the practical equivalent check. Whatever your platform, it is worth knowing that limit alongside the Oracle-side parameters, since Oracle cannot start more processes than the operating system will allow regardless of how MAX_DISPATCHERS or MAX_SHARED_SERVERS are set.

The instance's LREG background process is the one that registers dispatcher and service information with the listener at startup, not the other way around; the listener does not read shared server configuration out of the instance. Because of that, the listener genuinely does need to already be running for registration to happen promptly. If it is not, LREG retries periodically, and registration can be delayed by up to 60 seconds after the listener does come up. If you would rather not wait, issue:

ALTER SYSTEM REGISTER;

This forces immediate registration once the listener is available, which is particularly useful in high availability configurations where that delay matters.

Consider what this looks like in practice during a planned instance bounce. If you shut the instance down, restart the listener first (or simply leave it running throughout, since the listener does not need to go down at all), and then start the instance, LREG registers everything within its normal timeframe with no extra effort on your part. If instead the instance comes up first and the listener starts moments later, clients may see a brief window where connections fail or fall back unexpectedly until LREG's next registration attempt succeeds, which is exactly the scenario ALTER SYSTEM REGISTER exists to shortcut.

Most day to day changes to dispatcher or shared server configuration apply dynamically, without a database restart at all, as covered in Lessons 2 and 3; the listener-first ordering mainly matters around a full instance bounce, where both the listener and the instance are coming up from cold. A related, easily confused point: ALTER SYSTEM ... SCOPE=BOTH, used throughout this module to make a change persistent, only works if the instance uses a server parameter file (SPFILE). A traditional text based PFILE, the classic init.ora file, is still fully supported; it just cannot be written to by ALTER SYSTEM, so a PFILE based instance needs SCOPE=MEMORY plus a manual edit to make a change persist across a restart. The initialization parameters page in the database architecture course covers PFILE and SPFILE administration in more depth.

Connecting with (SERVER=DEDICATED) in the connect descriptor does not grant exclusive access to the instance; other sessions, dedicated or shared, keep connecting normally alongside it. The real reason to use a dedicated connection for certain administrative work, covered in Lesson 1, is that batch jobs and RMAN backup, restore, and recovery operations hold a server process for extended periods and should not compete with Shared Server's pool for it.

There is a separate, more fundamental reason certain administrative connections, starting up or shutting down the instance itself, work this way: at the moment those operations happen, the instance has no dispatchers registered with the listener to route through in the first place. Shared Server routing depends on an already-open instance with dispatchers up and registered; an instance that is not yet open, or is already on its way down, cannot offer that, which is why this kind of connection does not depend on Shared Server being available at all.

Lesson 2's SHARED_SERVER_SESSIONS parameter is the other side of this same coin. Where (SERVER=DEDICATED) lets one connection opt out of Shared Server, SHARED_SERVER_SESSIONS caps the total number of concurrent shared server sessions the instance will allow, which indirectly guarantees that some sessions remain available for dedicated connections even under heavy shared server load. The two work together: one gives an individual administrative connection an escape hatch, the other makes sure that escape hatch is not accidentally closed off by an unusually busy day.

Across this lesson, the theme has been the difference between what is fixed at configuration time and what Oracle adjusts on its own. Dispatcher counts, sized with the formula from Lesson 2, are relatively static; shared server counts, bounded between SHARED_SERVERS and MAX_SHARED_SERVERS, are actively managed by PMON in response to real load. Knowing which parameters describe a fixed configuration and which describe the boundaries of something Oracle manages dynamically is most of what "explaining the function" of these parameters actually means.

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