Lesson 1

Multi-Threaded Server (MTS) was renamed Oracle Shared Server beginning with Oracle 9i; the rename was cosmetic, the architecture it describes is still exactly what runs today in Oracle AI Database 26ai. This module looks at how Shared Server actually works, how it differs from a dedicated server connection, and when it's still the right choice.

Where a dedicated server gives each session its own process, Shared Server lets many client sessions share a small pool of server processes instead:

1. The client connects to the listener.
2. The listener hands the session to a dispatcher, or redirects the client to the dispatcher's own address.
3. The dispatcher keeps the network session and binds it to a virtual circuit in shared memory.
4. The dispatcher places the request on the common request queue, in the large pool.
5. An idle shared server picks up that request, does the SQL or PL/SQL work, then places the result on that dispatcher's response queue.
6. The dispatcher sends the result back to the client.

The next call from that same session can be handled by a completely different shared server. That's exactly why session state lives in the UGA, inside the SGA, rather than in a private process PGA the way it does under a dedicated server, there's no guarantee the same server process will ever see that session again.

The listener registration process, LREG, is what makes this work automatically: it registers each dispatcher's location and current load with the listener, so new connections get routed to a less busy dispatcher rather than piling onto one.

The six steps above read as a sequence; walking through what a single query actually experiences makes the design easier to hold onto. Say an application session, already connected through a dispatcher, runs a query.

1. The dispatcher receives the request over the existing network connection and places the session's virtual circuit on the common request queue, it doesn't process anything itself.
2. Whichever shared server happens to be idle at that moment picks the request up, there's no assignment of a specific shared server to a specific session, any idle one will do.
3. That shared server reads the session's state from its UGA in the SGA, where all session data lives so that any shared server can serve any session, runs the query, and writes the result back to the dispatcher's response queue.
4. The dispatcher, still holding the original network connection, sends the result back to the client.

If that same session runs a second query a moment later, it's entirely possible a different shared server picks it up this time. That's not a bug or an inefficiency to work around, it's the whole point: no server process is ever idle-but-reserved for a session that isn't actively doing anything, which is exactly what lets a small pool of shared servers support a much larger number of connections than dedicated servers could with the same process count.

Shared Server is off by default (SHARED_SERVERS = 0) unless dispatchers are already configured. Enable it with a non-zero shared server count; Oracle starts a TCP dispatcher automatically if you haven't defined one yourself:

ALTER SYSTEM SET SHARED_SERVERS = 4;
ALTER SYSTEM SET MAX_SHARED_SERVERS = 20;
ALTER SYSTEM SET DISPATCHERS = '(PROTOCOL=TCP)(DISPATCHERS=2)';

A database created with DBCA typically already has an XDB-only dispatcher, so SHARED_SERVERS may show 1 even though regular sessions still use dedicated servers. Set DISPATCHERS yourself when you need a non-TCP protocol, a fixed port, multiplexing, or a specific listener. A client can force which handler it wants directly in the connect string:

(SERVER=shared)
(SERVER=dedicated)
(SERVER=pooled)

If the client doesn't specify SERVER, Oracle assumes shared when dispatchers exist, and falls back to dedicated if none are available. (SERVER=pooled) is Database Resident Connection Pooling, DRCP, a genuinely different feature from Shared Server, not another name for it.

In a container database, Shared Server is configured at the root. A pluggable database can set SHARED_SERVERS = 0 to refuse shared servers entirely, or reset the parameter to inherit the root's setting again.

On-premises and in RAC, DBCA still defaults to dedicated servers; Shared Server remains optional, and a RAC database can run both models at once once dispatchers are configured, with connection load spread across them. On Autonomous Database Dedicated, Shared Server can be enabled at Autonomous Container Database creation specifically to let legacy applications that never implemented connection pooling scale without code changes; once enabled that way, every database in that container uses shared servers, dedicated isn't selectable per PDB, and no connect-string changes are required on the application side.

Sizing the large pool correctly matters here: it holds the request and response queues along with session UGA, and Shared Server contention shows up specifically in dispatcher and shared-server wait views when it's undersized.

A concrete case worth having in mind: an older reporting application, built years before connection pooling was standard practice, that opens a new database connection per user session and holds it open all day even though the user is actively querying for only a few minutes total. Multiply that by a few thousand users and dedicated servers would mean a few thousand mostly-idle server processes consuming memory and OS resources for no real work. Shared Server handles exactly this pattern well: a modest pool of dispatchers and shared servers services all of them, because at any given instant only a small fraction are actually running a query.

Oracle's documentation is candid that Shared Server is a trade-off. Database Concepts lists its benefits, fewer operating system processes, less PGA memory, more clients connected at once, and possibly faster connects when clients connect and disconnect at a high rate, alongside its disadvantages: slower response time in some cases, incomplete feature support, and more complex setup and tuning. Its general guideline is to use Shared Server only when you have more concurrent connections than the operating system can handle. The Administrator's Guide adds that batch jobs with little or no idle time, and RMAN backup and recovery, should connect through a dedicated server, and that administrative connections to start or shut down an instance or perform media recovery must use one.

For applications that acquire a connection, use it briefly, and release it, Database Resident Connection Pooling is a further option. Oracle's own worked example assumes 400 KB of memory per session, 4 MB per server process, a pool of 100, and 100 shared servers: with 5,000 client connections, dedicated servers use about 22 GB, Shared Server about 2.5 GB, and DRCP about 615 MB.

After completing this module, you'll be able to:

1. Describe how Shared Server differs from a dedicated server connection
2. Identify the components of Shared Server, dispatchers, virtual circuits, the common request queue, and shared server processes
3. Configure Shared Server, including the CDB/PDB-level behavior of its parameters
4. Recognize when Shared Server, dedicated servers, or DRCP is the right fit

The next lesson examines the reasoning behind Shared Server's design in more depth.