Oracle Shared Server and Incoming Connections

Four tier architecture.

1. Nginx server receives requests from the Client web browser.
2. Apache Tomcat can contain the application logic (beans, servlets, JSPs) handling the data received from Nginx.
3. Oracle Shared Server manages the connections to the Oracle RDBMS.
4. Oracle RDBMS holds the relational data.

A classic and very common four-tier architecture for web applications, where each tier's role is defined. Let's re-emphasize and expand slightly on each point to solidify the understanding:

1. Client Tier (Web Browser):
   • Role: The end-user's interface. This is where the user interacts with the application.
   • Communication: Initiates HTTP/HTTPS requests to the web server (Nginx).
   • Your Point: "Nginx server receives requests from the Client web browser." - Correct. This is the first point of contact for the web application.
2. Web Server Tier (Nginx):
   • Role: Acts as the entry point for all client requests. Primarily handles static content, acts as a reverse proxy, load balancer, and SSL terminator.
   • Communication:
     • Receives HTTP/HTTPS requests from clients.
     • Serves static files (HTML, CSS, JavaScript, images) directly if applicable.
     • For dynamic content, it forwards (reverse proxies) requests to the application server (Apache Tomcat).
   • Your Point: "Nginx server receives requests from the Client web browser." - Correct, but also implicitly forwards dynamic requests.
3. Application Server Tier (Apache Tomcat):
   • Role: Contains the core business logic of the application. Processes dynamic requests, interacts with the database, and generates dynamic content.
   • Components: This is where your Java components (Servlets, JSPs, Spring Beans, EJBs if it were a full Java EE server like WebLogic/JBoss) reside and execute.
   • Communication:
     • Receives requests forwarded from the web server (Nginx).
     • Processes the business logic.
     • Makes database connection requests to the Oracle RDBMS (via JDBC/Oracle Net Services).
     • Receives data from the RDBMS.
     • Generates dynamic content (e.g., HTML) and sends it back to the web server (Nginx).
   • Your Point: "Apache Tomcat can contain the application logic (beans, servlets, JSPs) handling the data received from Nginx." - Correct.
4. Database Connection Management Tier (Oracle Shared Server):
   • Role: Part of the Oracle RDBMS, specifically designed to efficiently manage incoming connections from application servers (like Tomcat). It allows multiple client sessions to share a smaller pool of server processes, optimizing resource usage.
   • Communication: Receives connection requests and SQL queries from the application server (Tomcat) via Oracle Net Services. Hands off these requests to available shared server processes within the RDBMS.
   • Your Point: "Oracle Shared Server manages the connections to the Oracle RDBMS" - Correct. It's the gatekeeper and dispatcher for database access.
5. Database Tier (Oracle RDBMS):
   • Role: The persistence layer. Stores, manages, and retrieves all the application's structured data. This includes tables, indexes, stored procedures, etc.
   • Communication: Receives SQL queries from the shared server processes, executes them, and returns the results.
   • Your Point: "Oracle RDBMS holds the relational data" - Correct. This is where your actual data resides.

This architecture provides excellent scalability, flexibility, and separation of concerns, which are key benefits of multi-tier designs. Each tier can be independently scaled, maintained, and secured.

While Oracle 23ai still supports Shared Server, its necessity and prominence are significantly reduced in Oracle Cloud Infrastructure (OCI) deployments, especially with services like Autonomous Database.
Here is why:

1. Autonomous Database (ADB) and Managed Services:
   • Abstraction: For Autonomous Database (both Shared and Dedicated Exadata Infrastructure), Oracle handles the underlying infrastructure, including connection management, scaling, and resource allocation. You, as the user, don't directly configure or even see Shared Server. Oracle's automation and internal mechanisms optimize connections for you.
   • Built-in Optimization: ADB is designed for high concurrency and elastic scaling. It uses its own sophisticated internal connection pooling and resource management to ensure optimal performance without requiring manual Shared Server configuration.
   • Focus on Application Continuity: Oracle's focus in the cloud is on "Application Continuity" which aims to make application downtime transparent. This often involves client-side connection pooling and the database's ability to seamlessly re-establish sessions, rather than relying on Shared Server for connection multiplexing at the database level.
2. Base Database Service (VM DB Systems) and Exadata Database Service:
   • More Control, but Still Less Need: If you're running Oracle 23ai on a Base Database Service (VM DB System) or Exadata Database Service in OCI, you have more control over the database configuration compared to Autonomous Database. In these environments, you could technically configure Shared Server, just as you would on-premises.
   • OCI's Scalability and Network: However, the architecture of OCI itself, with its highly scalable network and compute resources, often makes the traditional benefits of Shared Server less critical.
     • Scaling Up/Out: It's often more straightforward to scale up the VM's resources or scale out with RAC (Real Application Clusters) if you need higher concurrency.
     • Connection Pooling in Middleware: Modern application servers (like Tomcat or WebLogic) and client applications use robust connection pooling mechanisms (e.g., UCP, HikariCP, DBCP) that are highly efficient. These pools manage the connections from the application tier to the database, effectively reducing the number of physical connections the database needs to handle concurrently. The overhead of a dedicated server process per connection becomes less of a concern when connections are managed and reused by a well-tuned application-side pool.
     • Oracle Connection Manager (CMAN): For complex network topologies, security, or specific multi-tenant scenarios, Oracle Connection Manager (CMAN) might be used. CMAN can provide connection multiplexing and traffic management outside the core database instance, acting as an intelligent proxy. This can sometimes fulfill roles that Shared Server might have handled in older, simpler configurations.

In essence:

• For Autonomous Database, you generally don't configure or need to worry about Shared Server. Oracle manages it for you.
• For Base Database Service / Exadata Database Service in OCI, while technically possible, the need for Shared Server is significantly diminished. Modern best practices emphasize efficient client-side connection pooling and leveraging OCI's native scalability features.

So, while the technology is still present within the Oracle Database software (23ai), its practical application and necessity have shifted in the cloud-native paradigm, particularly with services like Autonomous Database.

The listener is a software program that runs on each remote node and listens for any incoming database requests. When a request is detected, the listener may direct the request to:

1. A dedicated server
2. A Shared server
3. An existing process or pre-spawned shadow process

When an Oracle database has been configured as a multi-threaded server, incoming connections are always routed to the dispatcher. However, a dedicated connection can be specifically requested by having SERVER=DEDICATED in the CONNECT_DATA portion of the connect descriptor. It is sometimes useful for transactions involving a high degree of activity to use a dedicated connection.
The next lesson discusses the architecture of MTS.