When you connect to an Oracle Database, you aren't just "opening a file." You are initiating a relationship between your client application and the server's CPU and memory.

Oracle offers two distinct ways to handle this relationship: Dedicated Server and Shared Server. Choosing the wrong one is like sending a 50-passenger bus to pick up one person—or trying to fit a football team into a Mini Cooper.

1. Dedicated Server: The "Private Chauffeur"

In a Dedicated Server architecture, for every single user that connects, Oracle spawns a brand-new dedicated server process (at the OS level) on the database server.

• How it works: User A connects $\rightarrow$ Process 101 is created. User B connects $\rightarrow$ Process 102 is created.

• The Relationship: 1 Client = 1 Server Process.

• Memory: The PGA (User Memory) is private to that OS process.

Best For:

• Long-running queries: Complex reports or heavy batch jobs.

• Low user count: When you have 50 users who stay active all day.

• DBA Tasks: High-priority administrative work.

2. Shared Server: The "Public Transit"

In a Shared Server architecture (formerly known as Multi-Threaded Server or MTS), Oracle uses a pool of "Shared Workers" to handle a much larger number of users.

• How it works: Instead of a private process, users talk to a Dispatcher. The Dispatcher puts the request into a "Common Queue." The next available Shared Server Process picks up the request, does the work, and hands it back to the Dispatcher.

• The Relationship: Many Clients = A few Dispatchers = A small pool of Shared Servers.

• Memory: Because any shared process might need to access your session data, the UGA (User Global Area) is moved out of the private PGA and into the SGA (Shared Memory).

Best For:

• High user concurrency: 1,000+ users who connect, do a tiny bit of work, and then sit idle.

• Web Applications: Where connections are frequent but very short-lived.

• Memory conservation: When you don't have enough RAM to give every user their own OS process.

3. Comparison at a Glance

4. The "Middle Man": The Dispatcher

The hero of the Shared Server model is the Dispatcher. Think of it like a barista at a coffee shop. You give your order to the barista (Dispatcher). They write it on a cup and put it in the line (Queue). A different person (Shared Server) makes the coffee and hands it back to the barista to give to you.

In a Dedicated model, you would walk into the coffee shop and a private barista would follow you around the store for three hours just in case you wanted a second sip.

5. Which one are you using?

Most modern databases use Dedicated Server by default because modern hardware has plenty of RAM to handle hundreds of processes. However, you can check your current session's status with this query:

SELECT server FROM v$session WHERE audsid = USERENV('sessionid');

• If it says DEDICATED, you have your own private process.

• If it says SHARED or NONE, you are part of a pool.

Pro-Tip: The Hybrid Approach

You don't have to choose just one! You can configure Shared Servers for your thousands of web users while keeping a Dedicated connection string for your DBAs and batch processing. This ensures that even if the Shared Server queue gets backed up, the DBA can still get in to fix the problem.