Lesson 1

The previous module introduced you to many of the issues surrounding the use of Shared Server, and especially some of the ways in which it differs from a dedicated server connection.

This module takes a much more practical look at Shared Server, investigating how Shared Server handles various types of incoming requests and how to manage and configure Shared Server for optimal performance.

After completing this module, you should be able to:

1. Identify dispatcher parameters
2. Configure the dispatcher for Shared Server
3. Configure multiple listeners with Shared Server
4. Specify relevant parameters for Shared Server servers
5. Set up connection pooling using Shared Server
6. Monitor Shared Server connections using UNIX and Oracle

The module begins with an examination of dispatcher parameters.

Both Shared Server and the Database Resource Manager help Oracle support larger or mixed user populations, though they solve different parts of the problem. Shared Server reduces the number of server processes an instance needs by letting many client sessions share a small pool of shared server processes. The Database Resource Manager, on the other hand, does not change how many processes exist; it controls how CPU time and other resources are divided among competing groups of sessions and jobs once they are connected. A busy instance typically benefits from both: Shared Server to keep the process count manageable, and Resource Manager to keep any one group of users or jobs from starving the rest.

Before looking at how to configure Shared Server, it helps to walk through what actually happens when a client connects. In a Shared Server configuration, client processes do not connect directly to a server process the way they do with a dedicated server. Instead, they connect to a dispatcher, a background process whose job is to receive requests from many clients and place them on a common request queue.

An idle shared server process picks the next request off that common queue, services it, and places the response on the dispatcher's own response queue, then goes back to waiting for another request. Because one shared server can service many different sessions in turn, a small pool of them can support a much larger number of connected clients than the same number of dedicated servers could.

The listener plays a coordinating role in all of this. The LREG background process registers each instance, and each dispatcher's location and current load, with the listener. When a new connection request arrives and Shared Server is configured, the listener uses that registration information to hand the request to a dispatcher directly, or, when the dispatcher is remote, to send the client a redirect message containing the dispatcher's address so the client can connect to it directly. If multiple dispatchers are registered, the listener favors whichever one is least loaded, which is what gives Shared Server its automatic load balancing across dispatchers.

Each client connection to a dispatcher is bound to a virtual circuit, a small piece of shared memory that carries the request and response traffic for that connection. This is also where Shared Server's memory tradeoff shows up: because a client's session state, its User Global Area or UGA, must remain available for the whole life of the session, and a shared server's own process memory is reused across many different sessions, the UGA for a Shared Server session cannot live in a private process memory area. Instead it is kept in the System Global Area, drawn from the shared pool or, where configured, the large pool. A dedicated server, by contrast, keeps the UGA in its own private process memory for as long as that one session lasts.

There are actually two different ways the listener can get a client connected to a dispatcher, and which one is used depends on the network protocol and operating system involved. The listener's preferred method is a direct hand off: it passes the connection request straight to the dispatcher itself, and the client is connected with no further involvement from the listener. When the dispatcher is remote to the listener, or a direct hand off is not possible, the listener falls back to a redirect: it sends the client a message containing the dispatcher's protocol address, the client's existing session to the listener ends, and the client opens a new session directly to that address. Either way, once the connection is established the listener steps out of the picture entirely; the client communicates with its dispatcher, and eventually a shared server, without the listener sitting in the middle of every request.

Oracle7 introduced the Multi-Threaded Server, commonly abbreviated MTS, specifically to let a single instance support larger user populations without paying the cost of one dedicated server process per client. Oracle9i renamed this same architecture Oracle Shared Server, and the name has stuck ever since; if you see "MTS" in older material, or in an initialization parameter file inherited from a much older system, it refers to exactly the same dispatcher and shared-server-process model described above.

Shared Server and MTS both cut down the number of server processes an instance needs, but neither one by itself reduces the number of physical network connections; each client still occupies its own network connection to a dispatcher or listener. Because network sockets, like server processes, are not an unlimited resource, Oracle has continued to add connection pooling technologies on top of Shared Server over the years, which is covered later in this lesson.

Additional background processes may appear when other features are in use alongside Shared Server, such as job queues and replication, but the shared server processes and dispatchers themselves are the core of the architecture this module focuses on.

It is worth being direct about how much of this has changed recently: very little. The core Shared Server model, dispatchers, a common request queue, and a pool of shared server processes drawing sessions from that queue, has been architecturally stable across Oracle Database 19c, 21c, 23ai, and Oracle AI Database 26ai. If you configured Shared Server on a 19c instance, the mental model transfers directly to 26ai. Worth noting for anyone tracking version numbers: Oracle AI Database 26ai's own quarterly release updates are still numbered in the same "23" series used by the prior release, for example Release Update 23.26.0, so the version history behind 26ai runs continuously from that earlier release line rather than starting over.

What has changed are the technologies that sit alongside Shared Server rather than inside it. Starting with Oracle Database Release 21c, Database Resident Connection Pooling gained the ability to be configured per pluggable database, using the ENABLE_PER_PDB_DRCP parameter, so a PDB administrator can independently manage a connection pool for their own PDB rather than relying only on a database-wide setting. Starting with Oracle AI Database 26ai, Proxy Resident Connection Pooling gained implicit connection pooling, letting applications that do not already use a connection pool such as the Oracle Call Interface Session Pool or the Java Universal Connection Pool get pooling benefits automatically, with no application code changes required.

Also new in Oracle AI Database 26ai: password-based administrative access to Oracle Connection Manager is desupported. Administrators who previously used a CMAN password should remove it and rely instead on Local Operating System Authentication, which restricts administrative operations to the operating system user who started the Connection Manager instance, consistent with how Oracle Database handles other operating-system-based authentication.

None of this changes the fact that a database is always enabled to accept dedicated server connections; that capability requires no configuration at all. Shared Server, by contrast, must be explicitly enabled, which is exactly what the rest of this module walks through.

Because Shared Server reduces server processes rather than network connections, Oracle provides several complementary pooling technologies that address connection overhead more directly. These work at different layers, and it is worth knowing which is which before configuring any of them:

• Database Resident Connection Pooling (DRCP) maintains a pool of "dedicated"-equivalent servers inside the database itself, managed by a connection broker process. It is aimed squarely at applications with short-lived connections, such as a web application that acquires a connection, does a small amount of work, and releases it, and it is especially useful for multi-process, single-threaded application server architectures that cannot maintain their own middle-tier connection pool.
• Proxy Resident Connection Pooling (PRCP) provides pooling on Oracle Connection Manager in Traffic Director Mode, and can be configured either per database service or for an entire pluggable database.
• Implicit connection pooling, new in Oracle AI Database 26ai, is a capability of PRCP rather than a separate pool of its own. It automatically maps a database session to and from an application connection at runtime, detecting when a request or transaction has ended and releasing the session back to the pool without the application having to call any pooling API.

Each of these can be used together with either a dedicated or a Shared Server configuration; they are not a replacement for Shared Server, but additional tools for reducing connection overhead once Shared Server itself is in place. DRCP in particular is worth calling out for its resource impact: because it lets many middle-tier processes, and even many middle-tier hosts, share a single pool of database-side connections, it can significantly cut down the database tier's memory footprint compared with each middle-tier process opening its own connection, while also avoiding the repeated cost of creating and tearing down connections for short-lived requests. Lesson 5 of this module returns to connection pooling in more detail.

Configuring Shared Server does not mean every session should use it. Oracle recommends connecting through a dedicated server, even on an instance where Shared Server is fully configured, in a couple of specific situations. A batch job that keeps its server process continuously busy, with little or no idle time, gains nothing from sharing a server with other sessions, and holding a shared server for that long can leave fewer shared servers available for everyone else. Recovery Manager (RMAN) operations, backing up, restoring, or recovering the database, should also connect through a dedicated server rather than Shared Server.

To force a dedicated server connection when Shared Server is configured, add (SERVER=DEDICATED) to the CONNECT_DATA section of the relevant connect descriptor. Administrators who want to guarantee that dedicated sessions are always available for this kind of work, rather than hoping enough shared servers happen to be free, can also set the SHARED_SERVER_SESSIONS parameter to reserve a number of sessions specifically for dedicated connections, so that administrative tasks are never preempted by an unusually busy shared server workload.

This module's first objective is to identify dispatcher parameters, so it is worth previewing the small set of initialization parameters that govern Shared Server before the next lesson configures them in detail:

• SHARED_SERVERS enables Shared Server: setting it to a nonzero value turns Shared Server on, and Oracle will start at least one dispatcher automatically even if none has been explicitly configured.
• DISPATCHERS configures the dispatcher processes themselves, including their network protocol and, optionally, how many of each type to start.
• 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 needed.
• MAX_SHARED_SERVERS limits 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 at night.
• CIRCUITS sets a limit on the total number of virtual circuits available for both inbound and outbound sessions, protecting shared memory from being exhausted by an unexpectedly high number of connections.

The next lesson picks up each of these in turn, along with how to monitor dispatcher load using views such as V$DISPATCHER, V$DISPATCHER_RATE, and V$QUEUE.

The last learning objective for this module is monitoring Shared Server connections using both UNIX and Oracle, and the two approaches answer different questions. On the operating system side, a dedicated server connection is easy to spot: each one is its own process, so a UNIX or Linux ps command shows a separate process per connected session. A Shared Server connection does not work this way; many sessions share a much smaller number of shared server and dispatcher processes, so ps alone cannot tell you how many client sessions are actually active.

That is where Oracle's own dynamic performance views take over. The V$QUEUE view shows how long requests have been waiting in the common request queue, which is the clearest early signal of contention for shared servers. A simple query against V$SHARED_SERVER, filtered to processes that have not yet quit, shows how many shared servers are currently running. Later lessons in this module put both of these views to work directly, alongside V$DISPATCHER and V$DISPATCHER_RATE, to build a complete picture of how busy a Shared Server configuration actually is.

A client is any application that connects to the Oracle database to send or retrieve data. An Oracle client application can reside on any machine, provided it has Oracle client software installed. Oracle Net is the software component that resides on both the client and the Oracle database server; it establishes and maintains the connection between the client application and the server, and exchanges messages between them using industry standard protocols. For a client application and a database to communicate, the client application must specify location details for the database it wants to connect to, and the database must in turn expose some form of identification or address for that client to reach it by. Everything covered in this module, from dispatchers to connection pools, sits on top of this basic Oracle Net foundation.