How Oracle Net Services Handles Connections in Oracle 23ai

Oracle Net is a layer of software that allows different physical machines to communicate for the purpose of accessing an Oracle database. It resides on both the client and the database server, establishing and maintaining connections between client applications and Oracle Database across industry-standard network protocols. When a connection request is made through Oracle Net, it passes the request to its underlying foundation layer — the Transparent Network Substrate (TNS) — where the request is transmitted to the appropriate server. At the server, Oracle Net receives the request from TNS and passes the SQL to the database for processing. This fundamental architecture has remained consistent from SQL*Net through Oracle Net Services and into Oracle 23ai. Newer enhancements — TLS 1.3 encryption, Centralized Configuration Providers, token-based OCI IAM authentication — extend the capabilities of this architecture without changing its core TNS-based foundation.

The Oracle Net Services Layer Architecture

Oracle Net Services is composed of three distinct layers that interact to locate services, establish connections, transport data, and handle exceptions:

1. Oracle Net Foundation Layer: The primary Oracle Net layer built on TNS technology. It handles generic connectivity tasks — resolving service names, establishing and maintaining connections, managing session state, and exchanging messages between client and server. The Oracle Net Foundation Layer is the component that application drivers (JDBC, OCI, ADO.NET, ODBC) interact with directly.
2. Oracle Protocol Support Layer: Maps Oracle Net Foundation Layer operations to the specific network protocol in use — primarily TCP/IP or TCPS (TCP with TLS). The Protocol Support layer translates generic Oracle Net send/receive operations into the protocol-specific packet format required by the underlying network. In Oracle 23ai, the Protocol Support layer handles TLS 1.3 handshake negotiation for TCPS connections.
3. Oracle Net Listener: The server-side process that receives incoming connection requests on the configured protocol address (default TCP port 1521 or TCPS port 2484) and routes them to the appropriate database instance or shared server process. After the initial connection handoff, the Listener steps out of the communication path for dedicated server connections — subsequent client-to-server communication occurs directly between the client Oracle Net layer and the server Oracle Net layer without Listener involvement.

TNS sits within the Oracle Net Foundation Layer as the core abstraction technology. It provides a single, common interface to all industry-standard protocols — making connectivity transparent to the application regardless of the underlying network protocol, physical machine separation, or geographic distance between client and server. At the lowest level, TNS communicates between peers using message-level send, receive, open, and close operations that are protocol-independent.

The Client Side — Oracle Call Interface and Modern Drivers

The original Oracle client-side programmatic interface was the User Programmatic Interface (UPI) — an internal Oracle component that converted SQL statements into the parse, execute, and fetch operations required by the Oracle server protocol. The UPI opened SQL cursors, bound application variables to SQL parameters, described returned data fields, fetched result rows, and closed cursors. Oracle minimized network round-trips by combining multiple UPI calls into single network messages wherever possible.

The UPI has been superseded in modern Oracle architectures by the Oracle Call Interface (OCI) and its language-specific wrappers. The programmatic interfaces available to application developers in Oracle 23ai are:

• Oracle Call Interface (OCI): The primary C-language API for Oracle database access. OCI provides function calls that control all phases of SQL statement execution — connection establishment, statement preparation, bind variable management, execution, fetch, and resource cleanup. All higher-level Oracle client drivers (JDBC OCI driver, ODP.NET, Oracle provider for OLE DB) are built on OCI.
• JDBC Thin Driver: A pure Java implementation of the Oracle Net protocol that communicates directly with the Oracle Net Foundation Layer without requiring a local Oracle client installation. The JDBC Thin driver is the standard connectivity choice for Java applications connecting to Oracle 23ai, including applications running in containers and cloud-native environments.
• Microsoft.Data.SqlClient / ODP.NET: The .NET managed driver for Oracle connectivity, providing Oracle Net access from C#, VB.NET, and F# applications.
• ODBC Driver for Oracle: Provides Oracle Net connectivity to applications using the standard ODBC interface — including business intelligence tools, reporting platforms, and legacy applications that predate OCI.
• Precompiler Interface (Pro*C/C++, Pro*COBOL): A compile-time tool that enables embedding SQL statements directly in C, C++, and COBOL source code. The precompiler translates embedded SQL into OCI calls before compilation. This interface remains supported in Oracle 23ai for legacy application compatibility.

All client-side interfaces ultimately communicate with the Oracle Net Foundation Layer to establish connections and exchange data with the Oracle server — the interface layer above Oracle Net varies by language and application type, but the Oracle Net communication path is consistent across all of them.

The Server Side — Oracle Programmatic Interface and Server Processes

The Oracle Programmatic Interface (OPI) is the central server-side component — the counterpart to the client-side UPI/OCI layer. The OPI responds to all messages from the client Oracle Net layer, processes the SQL or PL/SQL request against the Oracle database kernel, and returns results through the Oracle Net Foundation Layer to the client.

Three server process modes handle incoming client connections in Oracle 23ai:

• Dedicated Server: Each client connection spawns a dedicated server process on the database server that serves only that client for the duration of the session. The dedicated server process handles all OPI operations for its client — parsing, executing, fetching, and returning results. Dedicated server is the default connection mode and is appropriate for long-running sessions with sustained database activity.
• Shared Server (formerly Multi-Threaded Server): A pool of shared server processes handles requests from multiple client sessions. Client sessions connect to a dispatcher process that queues requests to available shared server processes. Shared server reduces per-connection memory overhead for environments with many concurrent short-lived connections. Configured through the DISPATCHERS and SHARED_SERVERS initialization parameters.
• Database Resident Connection Pooling (DRCP): A server-side connection pool introduced in Oracle 11g and enhanced in Oracle 23ai. DRCP maintains a pool of server processes that are leased to client connections on demand and returned to the pool when the client's work unit completes. DRCP is particularly effective for mid-tier application servers and web applications that establish many short-duration database connections.

For server-to-server communication — distributed queries across database links as covered in Lessons 8 and 9 — there is no client-side UPI or OCI layer at the initiating server. Instead, the initiating server uses an internal server-to-server Oracle Net session where the local database acts as an Oracle Net client to the remote database. Network transparency is preserved: the SQL syntax for accessing remote tables through database links is identical to local table access syntax — location transparency is achieved through database links and synonyms exactly as described in earlier lessons.

Connection Handling Flow in Oracle 23ai

The complete connection handling sequence in Oracle 23ai from client request to active session:

1. The client application submits a connection request through its Oracle Net driver (JDBC, OCI, ODBC) specifying a connect identifier — either an Easy Connect Plus string or a tnsnames.ora alias.
2. The Oracle Net Foundation Layer resolves the connect identifier through the configured naming method (Easy Connect parsing, tnsnames.ora lookup, LDAP directory, or OCI Centralized Configuration Provider).
3. The Oracle Protocol Support layer establishes a TCP or TCPS connection to the resolved host and port. For TCPS connections in Oracle 23ai, TLS 1.3 handshake negotiation occurs at this step.
4. The Oracle Net Listener on the server receives the incoming connection request, validates the requested service name against its registered services, and either hands off the connection to a dedicated server process, routes it to a dispatcher for shared server mode, or assigns it a DRCP pooled server process.
5. The server process authenticates the client using the credentials provided — password authentication, OS authentication, Kerberos, wallet-based certificate, or OCI IAM token in Oracle 23ai environments.
6. The Oracle Net Foundation Layer on the server side signals connection establishment to the client. The Listener exits the communication path for dedicated server connections — subsequent communication occurs directly between the client Oracle Net layer and the server Oracle Net layer through the established TCP/TCPS connection.
7. The client application issues SQL through its programmatic interface (OCI, JDBC, etc.). Oracle Net packages the SQL into TDS-equivalent Oracle Net protocol packets and transmits them to the server Oracle Net layer, which passes them to the OPI for execution against the Oracle Database kernel.

Oracle Net Features in Oracle 23ai

The core Oracle Net architecture described above is extended in Oracle 23ai with several capabilities that were not present in earlier releases:

• TLS 1.3 as default for TCPS connections: Stronger cipher suites and a more efficient handshake than TLS 1.2. System wallets simplify one-way TLS by eliminating the client wallet requirement when the server certificate is signed by a recognized root CA.
• Token-based authentication (OAuth 2.0 / OCI IAM): Clients present time-limited OCI IAM tokens rather than static passwords. The Oracle Net authentication layer validates tokens against OCI IAM without requiring a database-stored password.
• Centralized Configuration Providers: tnsnames.ora content stored as JSON in OCI Object Storage or Azure App Configuration and retrieved by Oracle Net at connection time — eliminating client-side configuration file management.
• Larger default SDU (64 KB): The Session Data Unit size increase on the server side reduces the number of network round-trips required for large result set transfers without manual configuration changes.
• TCP Fast Open: Reduces connection establishment latency for high-frequency connection patterns common in OCI and Autonomous Database environments.

Summary

Oracle Net Services handles connections through a three-layer architecture: the Oracle Net Foundation Layer built on TNS provides protocol-independent connectivity; the Oracle Protocol Support layer maps Oracle Net operations to TCP/IP or TCPS; and the Oracle Net Listener receives and routes incoming connection requests to dedicated server, shared server, or DRCP pooled server processes. The OPI on the server side processes all SQL requests received through Oracle Net and returns results to the client Oracle Net layer. The UPI/OCI client-side interface packages SQL into Oracle Net messages for transmission. This architecture has remained the foundation of Oracle connectivity from SQL*Net through Oracle 23ai — newer capabilities including TLS 1.3, OCI IAM token authentication, and Centralized Configuration Providers extend but do not replace the core TNS-based connection handling model. The next lesson examines Oracle Net Services as the successor to SQL*Net and covers the evolution of Oracle networking from SQL*Net version 1 through Oracle Net Services.