Shared Server and Dedicated Server: One Listener, Different Handlers

Worth clearing up before anything else: Shared Server and a dedicated server connection aren't two kinds of listener. The Oracle Net Listener is exactly the same process in both cases; its job is only to accept an incoming connection, pick a service handler, and hand the session off. That handler is one of three things: a dedicated server process, a dispatcher for Shared Server, or a pooled server for Database Resident Connection Pooling (DRCP). There's no separate "dedicated listener" product, what people usually mean by that phrase is a dedicated server process, or sometimes a listener configured to serve only one service or port, a network layout choice that has nothing to do with Shared Server at all.

SQL*Net version 1.0 required the listener to spawn a distinct operating-system process for every new connection. SQL*Net version 2.0 introduced Multi-Threaded Server (MTS), which let a small set of dispatcher processes handle many connections instead. Oracle 9i renamed MTS to Shared Server, the same architecture under a new name, not a new invention. That architecture, dispatcher, request queue, shared server pool, response queue, is still exactly how Shared Server works in Oracle AI Database 26ai today, though the connectivity layer itself has moved well past that early SQL*Net naming, current clients typically connect through Easy Connect Plus or OCI-native methods rather than anything resembling those original SQL*Net-era configuration files.

	Dedicated server	Shared Server
After the listener	One server process is assigned per session	The session goes to a dispatcher (Dnnn)
Who talks to the client	The dedicated server process directly	The dispatcher
Who runs SQL	That same process, for the life of the session	Whichever shared server (Snnn) is free at the moment
Session memory	Mostly in the process's own PGA	The UGA, inside the SGA, since a different shared server may handle the next call
Process count	Grows with the number of connections	Stays small: a handful of dispatchers plus a handful of shared servers
Best suited to	Batch jobs and other work with little idle time, RMAN, administrative connections, and features Shared Server does not fully support	Many concurrent connections with intermittent activity, or a high connect and disconnect rate

Request paths look different too. Dedicated: client to listener to one dedicated server process to the database, staying attached to that same process until disconnect. Shared: client to listener to a dispatcher, which places the request on the SGA's common request queue; a shared server from the pool picks it up, does the work, and returns the result to the response queue, which the dispatcher sends back to the client. The network connection stays on the dispatcher throughout; only the SQL work itself gets borrowed from the shared server pool and released again.

The connect descriptor controls this directly:

(SERVER=dedicated)   -- a dedicated server process
(SERVER=shared)       -- dispatcher and shared servers
(SERVER=pooled)       -- DRCP, a separate feature from Shared Server

If a client omits SERVER and dispatchers exist, Oracle prefers Shared Server and falls back to dedicated automatically if no dispatcher is available. Both connection types can, and routinely do, run against the same database at the same time through the same listener, there's no need for two separate listener processes to support both, despite what older material sometimes claims.

Made concrete: imagine a single 26ai instance serving two different applications, a batch reporting job that opens one connection and runs a single, long, I/O-heavy query, and a web application with a few hundred short-lived sessions that mostly sit idle between requests. Nothing about that setup requires choosing one connection model for the whole database. The reporting job's connect string specifies (SERVER=dedicated), or simply omits SERVER in an environment where no dispatcher is configured, and gets its own process with exclusive access to its own PGA for the query's duration. The web application's connections specify (SERVER=shared), or rely on the default preferring shared when dispatchers exist, and get routed through whichever dispatcher is available, sharing a small pool of server processes across all those mostly-idle sessions. One listener, one instance, two connection models, chosen per client rather than per database.

Shared Server is a trade-off, not a universal upgrade. Oracle's Database Concepts guide lists slower response time in some cases, incomplete feature support, and more complex setup and tuning among its disadvantages, and the Administrator's Guide directs batch jobs that leave little or no idle time, and RMAN backup and recovery, to dedicated servers. Some features can also bind a session to a single shared server while they run; the Performance Tuning Guide's example is parallel execution. What Shared Server offers in return, fewer processes, less PGA memory, more connected clients, and possibly faster connects when clients connect and disconnect at a high rate, matters most for many connections that spend most of their time idle, not for a smaller number doing sustained work.

It can be genuinely hard to tell at a glance whether Shared Server is active, let alone whether it's healthy. Check v$parameter, or the current parameter file, for the SHARED_SERVERS and DISPATCHERS settings to confirm it's configured at all. Whether that parameter file is a traditional PFILE (init.ora), still fully supported today, or the more convenient SPFILE that supports persistent ALTER SYSTEM changes, doesn't change where these particular settings live. To see Shared Server actually working, query v$dispatcher for dispatcher status and load, and v$queue for request and response queue activity; a dedicated-only environment has no equivalent queues to check, since there's no shared queue in that model at all.
The next lesson takes a closer look at Shared Server and dedicated connections in more depth.