Lesson 14	SQL*Net Version 2 Features
Objective	Trace the listener and naming architecture from SQL*Net Version 2 through Oracle 23ai Dynamic Registration

From SQL*Net Version 2 to Oracle 23ai — Listener and Naming Architecture Evolution

SQL*Net Version 2 introduced the two architectural decisions that define Oracle network connectivity through Oracle 23ai: the tnsnames.ora lookup file separating connection aliases from physical connection details, and the standalone listener process replacing the embedded ORASRV connection handler. Every Oracle Net Services feature built across the subsequent 35 years — service naming, connection load balancing, RAC integration, Easy Connect Plus, and Oracle 23ai Dynamic Registration — is an extension of those two foundational decisions. This lesson traces the listener and naming architecture from SQL*Net v2 through each major Oracle release to Oracle 23ai.

The Two Foundational Decisions of SQL*Net Version 2

Decision 1 — tnsnames.ora: Separating Alias from Connection Details

SQL*Net Version 1 required every connection to embed the full connection information — protocol, hostname, and database name — directly in the connect string or in the TWO_TASK environment variable. The syntax t:host:database was explicit but fragile: when a server moved or a hostname changed, every application and script that referenced the connection required manual updating.

SQL*Net Version 2 introduced the tnsnames.ora file — a client-side lookup catalog that mapped short service name aliases to full connection descriptors. Applications connected using only the alias; Oracle Net resolved the alias to the protocol, host, port, and database name transparently. When a server moved, the DBA updated one entry in tnsnames.ora rather than updating every application. This separation between the connection identifier and the connection details is the architectural ancestor of every subsequent Oracle Net naming method — LDAP directory naming, Easy Connect Plus, and Oracle 23ai Centralized Configuration Providers all implement the same fundamental principle through progressively more sophisticated mechanisms.

Decision 2 — The Standalone Listener: lsnrctl Replaces ORASRV

SQL*Net Version 1 used a process called ORASRV as the server-side connection handler. It was started and stopped with tcpctl start and tcpctl stop — tightly coupled to the TCP/IP protocol and providing no support for protocol independence or connection routing.

SQL*Net Version 2 replaced ORASRV with a standalone listener process — started and stopped with lsnrctl start and lsnrctl stop — configured through a dedicated listener.ora file. The new listener was protocol-independent, could serve multiple database instances on the same server, and supported both dedicated server processes (one process per client connection) and shared server connections through a dispatcher. This is the same listener architecture that Oracle 23ai uses — lsnrctl is still the primary listener management command, and listener.ora is still the server-side configuration file for static service registration.

Figure 1 — SQLNet Version 1 vs SQLNet Version 2

The regenerated diagram below shows the architectural difference between SQL*Net v1 and SQL*Net v2 — the transition that established the tnsnames.ora and lsnrctl foundation.

SQL*Net version 1 vs SQL*Net version 2 architecture diagram: MARVIN client node with two
request paths, SQL*Net v2 left panel using tnsnames.ora lookup with ORA-12154 error handling
connecting to multi-threaded server, SQL*Net v1 right panel using hostname check with ORA-06105
and ORA-06114 error handling spawning dedicated process on CAD2 server — SQL*Net Version 1 vs SQL*Net Version 2 — the critical architectural transition of the late 1980s to early 1990s. SQL*Net v2 (blue panel) introduced the /etc/TNSNAMES.ORA lookup file — separating the connection alias from the physical connection details for the first time. SQL*Net v1 (orange panel) required the protocol, hostname, and database name embedded in every connect string. The v2 listener introduced lsnrctl management and support for both dedicated and multi-threaded shared server processes — the architectural foundation that Oracle Net Services builds on through Oracle 23ai.

SQL*Net Version 2 — The Complete Enhancement Set

Beyond the tnsnames.ora lookup file and the lsnrctl listener, SQL*Net Version 2 introduced three additional capabilities that addressed the limitations of the SQL*Net v1 single-protocol, single-process architecture:

Multi-protocol community access: SQL*Net v1 was bound to a single protocol per connection — a TCP/IP client could only connect to a TCP/IP server. SQL*Net v2 introduced the concept of communities — groups of computers sharing a common protocol (TCP/IP, LU6.2, IPX/SPX). SQL*Net v2 could cross community boundaries, converting between protocols automatically so that a TCP/IP client could query data on an LU6.2 IBM mainframe without the application knowing about the protocol conversion. The remote request specified only the database name — SQL*Net handled all protocol translation transparently.
Multi-threaded server (Shared Server): SQL*Net v1 spawned a dedicated operating system process for every client connection — one process per client, regardless of whether the client was actively executing a query or sitting idle between transactions. SQL*Net v2 introduced the multi-threaded server (MTS, later renamed Shared Server) — a pool of shared server processes handling requests from multiple client sessions through a dispatcher. This dramatically reduced per-connection memory overhead for environments with many concurrent short-lived connections. The Shared Server architecture introduced in SQL*Net v2 remains an Oracle Net Services feature through Oracle 23ai, complemented by Database Resident Connection Pooling (DRCP) introduced in Oracle 11g.
Oracle Connection Manager (CMAN): Net8 added a third listener type alongside the standard lsnrctl listener — the Oracle Connection Manager (CMAN), managed through cmctl start and cmctl stop using processes cmadm and cmgw. CMAN provided connection concentration (multiplexing many client connections through fewer server connections), protocol conversion between different network segments, and access control for incoming connections. At peak complexity, an Oracle server could have three separate listener processes running simultaneously: the standard listener, CMAN, and the MTS dispatcher. CMAN remains part of Oracle Net Services through Oracle 23ai, used for connection concentration in large-scale environments and firewall traversal scenarios.

The Naming Architecture Evolution — SQL*Net v2 to Oracle 23ai

The tnsnames.ora file introduced in SQL*Net v2 was the first step in a naming architecture that has evolved through five distinct generations:

Generation	Naming Method	How It Works
SQL*Net v1	Embedded connect string	Protocol, hostname, and database embedded directly in every connect string or TWO_TASK variable. No lookup file. No alias resolution.
SQL*Net v2 / Net8	Local naming (tnsnames.ora)	Client-side tnsnames.ora maps short aliases to full connection descriptors. One file per client machine. Updates require distributing new tnsnames.ora to all clients.
Oracle 9i / 10g	Directory naming (LDAP/OID)	Oracle Internet Directory (OID) or third-party LDAP stores connection descriptors centrally. Clients query the directory at connect time. Eliminates distributed tnsnames.ora maintenance.
Oracle 10g / 11g R2	Easy Connect	Inline connect string — host:port/service — requires no client configuration file. Simple TCP/IP connections only. No support for advanced RAC or failover configurations.
Oracle 19c / 23ai	Easy Connect Plus + Centralized Config	Easy Connect Plus extends inline syntax with TCPS, TLS parameters, timeouts, and retry counts. Centralized Configuration Providers store tnsnames.ora content as JSON in OCI Object Storage or Azure App Configuration — zero client-side file management required.

The Listener Architecture Evolution — ORASRV to Oracle 23ai Dynamic Registration

The listener architecture has evolved in parallel with the naming architecture across the same five generations:

Generation	Listener	Key Characteristic
SQL*Net v1	ORASRV (tcpctl start/stop)	Protocol-specific, no listener.ora, no service routing. One dedicated process per connection spawned directly by ORASRV.
SQL*Net v2 / Net8	listener (lsnrctl start/stop)	Protocol-independent, listener.ora for static configuration, dedicated and shared server process support. CMAN added as optional third listener component.
Oracle 9i / 10g	Oracle Net Listener	Service naming replaces SID registration. Connection load balancing across RAC instances. Fast Application Notification (FAN) integration for rapid failover detection.
Oracle 11g / 12c	Oracle Net Listener + DRCP	Database Resident Connection Pooling adds server-side connection pool managed by the listener. Multitenant CDB/PDB awareness introduced in 12c — listener routes to specific PDB.
Oracle 19c / 23ai	Dynamic Registration (LREG)	LREG background process registers database services with the listener automatically at startup and updates registration as services change — no manual listener.ora SERVICE entry required for most deployments. Listener receives TCPS connections on port 2484. ORA-12514 replaces ORA-06114 for unknown service errors.

Figure 2 — SQL*Net v2 Architecture vs Oracle 23ai Architecture

The Nano Banana 2 comparison diagram below places the SQL*Net v2 legacy architecture alongside the Oracle 23ai modern equivalent — same two-node client-to-server flow, 35 years of evolution in every component.

Oracle Net Services SQL*Net v2 Architecture vs Oracle 23ai Architecture: left panel shows
legacy SQL*Net v2 client MARVIN with tnsnames.ora lookup and LISTENER.ORA on CAD2 server; right
panel shows Oracle 23ai client with Easy Connect Plus TCPS TLS 1.3 and Local Naming paths, Oracle
Database 23ai with dynamic service registration LREG, PDB routing, and three server modes —
dedicated, shared, and DRCP pooled; center divider shows 35 years of listener evolution from
ORASRV to lsnrctl to Oracle 23ai — Oracle Net Services — SQL*Net v2 Architecture versus Oracle 23ai Architecture. The left panel preserves the SQL*Net v2 legacy reference: TNSNAMES.ORA client lookup, LISTENER.ORA server configuration, and dedicated or multi-threaded server process spawning. The right panel shows the Oracle 23ai equivalent: Easy Connect Plus with TLS 1.3 on TCPS port 2484, OCI Centralized Configuration Provider as the modern alternative to tnsnames.ora, dynamic service registration through LREG eliminating manual listener.ora SERVICE entries, and three server process modes — dedicated, Shared Server dispatcher, and DRCP pooled server. The center divider traces 35 years of listener evolution: ORASRV → lsnrctl → Oracle 23ai Dynamic Registration.

Oracle 9i — The Bridge from SQL*Net v2 to Oracle Net Services

Oracle 9i marked the formal renaming of SQL*Net to Oracle Net and SQL*Net Version 2 features to Oracle Net Services — not a replacement but a rebranding and significant extension of the SQL*Net v2 foundation. The key Oracle 9i additions that bridged SQL*Net v2 to the modern Oracle Net Services architecture:

Service naming standardized: The SERVICE_NAME parameter in tnsnames.ora CONNECT_DATA blocks replaced the SID parameter as the standard database identifier — service names are dynamic and can represent multiple database instances, enabling RAC transparency.
Oracle Net Manager: A centralized GUI tool replacing the manual editing of tnsnames.ora, listener.ora, and sqlnet.ora files with a graphical configuration interface. Oracle Net Manager could push configuration changes to remote servers — the predecessor to the Centralized Configuration Providers of Oracle 23ai.
Connection load balancing: The listener distributed incoming connections across multiple RAC instances based on current workload — the first generation of the Oracle Net RAC integration that culminated in Fast Connection Failover and Transaction Guard in Oracle 12c and 19c.
SSL/TLS support: Oracle Advanced Security introduced SSL/TLS encryption for Oracle Net connections through the TCPS protocol — the same TCPS protocol that Oracle 23ai uses with TLS 1.3 as the default. The foundation laid in Oracle 9i is directly visible in the right panel of the Nano Banana 2 diagram above.

Summary

SQL*Net Version 2 made two architectural decisions in the late 1980s that define Oracle network connectivity through Oracle 23ai: the tnsnames.ora lookup file separating connection aliases from physical details, and the lsnrctl listener replacing ORASRV with a protocol-independent, configurable server-side connection handler. The naming architecture evolved from tnsnames.ora through LDAP directory naming, Easy Connect, Easy Connect Plus, and OCI Centralized Configuration Providers — each generation preserving the core principle that applications should reference a logical identifier rather than physical connection details. The listener architecture evolved from lsnrctl with static listener.ora SERVICE entries through dynamic service registration via the LREG background process in Oracle 23ai — eliminating manual listener configuration for most deployments while adding CDB/PDB routing, DRCP pooled server support, and TCPS with TLS 1.3 as the default secure transport. The next lesson examines how Oracle Net Services manages distributed database connections.

Oracle SQL Net — Exercise

Before moving on to the next lesson, click the Exercise link below for hands-on practice in defining a TNS topology. This is the first step of the course project.
Oracle SQL Net — Exercise