Oracle Shared Server and Incoming Connections

Shared Server is a database connection management feature: it lets many client sessions share a small pool of server processes instead of each session getting its own. This lesson follows one incoming connection through Oracle AI Database 26ai from the client's first request to the reply, then places that path inside a typical web application stack and looks at where Shared Server is, and is not, used on Oracle Cloud Infrastructure.

1. The listener receives the request. Using the dispatcher load information that LREG has registered, the listener chooses a dispatcher. It hands the connection off directly when it can, and otherwise sends the client a redirect message with the dispatcher's address.
2. The client talks only to the dispatcher. From here on the listener is out of the picture. The dispatcher binds the connection to a virtual circuit, a piece of shared memory the dispatcher uses for the client's database requests and replies.
3. The dispatcher queues the work. It places the virtual circuit on the common request queue, in the SGA.
4. An idle shared server picks it up. A shared server process (Snnn) takes the virtual circuit from the queue, services the request, and relinquishes the circuit before taking another. It places the result on that dispatcher's response queue.
5. The dispatcher replies. It returns the result to the client, and the shared server is free for the next request from any session.

A small pool of shared servers therefore serves many concurrent clients, which is the whole point: the number of server processes tracks the amount of work in progress, not the number of connections. Lesson 3 covers the listener's part in more detail.

Two clients make the walk above easier to picture. Client A and Client B each connected through a different dispatcher, and both run a query at nearly the same moment.

1. Each dispatcher places its client's virtual circuit on the common request queue. There is only one request queue, shared by all dispatchers, which is what lets any idle shared server take any waiting request.
2. Two idle shared servers pick up the two circuits. Neither server knows anything about the client ahead of time; all the session information it needs lives in the SGA, where every shared server can reach it.
3. Each shared server finishes its request and places the result on the response queue belonging to the dispatcher that originally sent it. Each dispatcher has its own response queue, so a result always returns to the dispatcher that owns the client's network connection.
4. Both dispatchers return their results, and both shared servers go back to waiting on the common request queue. If Client A runs a second query a moment later, either server may take it.

The clients never see any of this. From their side a session is one continuous connection to the database, which is exactly what the dispatcher is there to preserve.

If every shared server is already working, new requests do not fail; they wait on the common request queue until a server becomes free. That queue is also what drives adjustment: SHARED_SERVERS sets the minimum number of servers, and Oracle adjusts the actual number according to how busy the existing servers are and how long the request queue is, up to MAX_SHARED_SERVERS. A queue that keeps growing and does not drain is the signal that the pool is too small or that a few long-running requests are occupying servers that many short requests need.

That last point explains why Shared Server suits many short, intermittent requests and fits poorly around long, continuous ones. A shared server working on a request cannot serve anyone else until it finishes, so a handful of long requests can hold servers that dozens of quick ones are waiting for. Work like that belongs on a dedicated server, which is why the previous section lists batch jobs and RMAN among the cases that should use one.

Configuring Shared Server does not force every connection through a dispatcher. The listener selects a service handler for each request, and the handler can be a dedicated server as well as a dispatcher. A client can ask for a dedicated server explicitly with SERVER=DEDICATED in the CONNECT_DATA section of the connect descriptor. A client that does not say which it wants is served by a dedicated server if no dispatcher is registered. A client that explicitly asks for SERVER=SHARED when none is available is rejected. Some work must use a dedicated server whatever the configuration: administrative connections that start or shut down the instance or perform media recovery, batch jobs that leave little or no idle time, and RMAN backup and recovery.

A common web application has four layers, and it helps to be exact about where Shared Server belongs:

1. Browser. The end user's interface, sending HTTP or HTTPS requests.
2. Web server (for example Nginx). The entry point: it serves static files, terminates SSL, balances load, and forwards dynamic requests as a reverse proxy.
3. Application server (for example Apache Tomcat). Runs the business logic, servlets, JSPs, and beans, and opens the database connections, usually through a connection pool such as UCP, HikariCP, or DBCP, using JDBC over Oracle Net Services.
4. Oracle Database. Stores the data and serves the sessions the application server opens.

Shared Server is not a fifth layer between Tomcat and the database. It is part of how the database instance serves those sessions: the listener, dispatchers, queues, and shared servers described above all live inside the database tier. From the application server's side, the only visible choice is what the connect descriptor says, SERVER=SHARED, SERVER=DEDICATED, or nothing at all.

Shared Server is fully supported in Oracle AI Database 26ai and is still not the default. How much you use it depends on the service:

• Autonomous Database on Dedicated Exadata Infrastructure: Shared Server is an option you choose when you provision the Autonomous Container Database, and it then applies to every database in that container. The default is dedicated. Once it is on, you do not change the connect string, but you also cannot disable it for one database or use a dedicated connection to a database in that container. Oracle positions it for maintaining legacy applications designed without connection pooling.
• Base Database Service and Exadata Database Service: you manage the database, so you can configure Shared Server exactly as you would on-premises, with the parameters covered in the previous lesson.

Several other tools address connection volume from different angles, and they are complements more often than replacements:

• Application-side pools such as UCP, HikariCP, and DBCP reuse a limited set of connections, so the database sees fewer sessions. Shared Server instead reduces the number of server processes needed for the sessions that exist.
• Database Resident Connection Pooling (DRCP) pools server processes inside the database and is requested with SERVER=POOLED; it is a separate feature from Shared Server.
• Oracle Connection Manager multiplexes many client sessions through a single network connection. With dispatchers configured with MULTIPLEX=on, Connection Manager can funnel many clients into one connection to a dispatcher, so it builds on Shared Server rather than replacing it. The trade-off is that clients must connect through Connection Manager.
• Scaling up or adding RAC nodes adds capacity, but does not reduce the number of processes each connection requires.

lsnrctl services shows which handlers the listener knows about and whether each is a dedicated server or a dispatcher. V$DISPATCHER and V$SHARED_SERVER show the dispatchers and shared servers themselves, V$CIRCUIT shows the virtual circuits, and V$QUEUE shows the request and response queues. Together they tell you whether connections are reaching dispatchers and whether the shared server pool is keeping up.

The next lesson looks at the Shared Server architecture in more detail.