Oracle Net Communication with Client PCs

Oracle Net Services form the bridge between client PCs and the Oracle Database system — the layer responsible for getting a SQL statement from wherever a user typed it to wherever the data actually lives, and getting the results back again. Understanding how the pieces fit together matters for administration and troubleshooting alike: when a connection fails, knowing which component is actually responsible narrows down where to look.

Three components do most of the work:

1. Oracle Net — formerly known as SQL*Net, the software layer that provides network communication between a client application and an Oracle Database server. It establishes and maintains the connection, carries SQL commands and results in both directions, and insulates both sides from the specifics of whichever underlying network protocol is actually in use.
2. Oracle Net Listener — a process that runs on the database server, waiting for incoming connection requests. Once a request arrives, the listener starts a dedicated server process to handle that client's session.
3. Oracle Connection Manager — an optional proxy component that sits between clients and database servers. It provides connection concentration (handling a large number of simultaneous client connections efficiently against a single database server), access control, and network traffic filtering. Oracle Connection Manager has grown since older material described it: it now also supports a Traffic Director Mode, an additional operating mode built for distributing and load-balancing connections across multiple database instances, on top of its original proxy role.

Client PCs are the end-user machines running client applications — Oracle tools like SQL*Plus, or third-party applications using Oracle's APIs. They connect using Oracle's client software, which communicates with Oracle Net Services to send requests and retrieve results.

The Oracle Database system is where the data actually lives, operating on a client-server model: multiple client PCs can access and manipulate data concurrently. The database processes SQL commands received from clients, performs the requested operations, and returns results back through the same Oracle Net path.

Put together, here's the full round trip: a client PC sends a SQL command to the Oracle Database server via Oracle Net. The Oracle Net Listener receives the connection request and starts a dedicated server process to handle it. The database server executes the operation and sends results back to the client PC, again over Oracle Net. Where Oracle Connection Manager is in the picture, it manages the connection itself — concentrating many client connections efficiently, or, in Traffic Director Mode, distributing them across multiple database instances — without either side needing to know it's there.

A key component of Oracle Net is the Oracle Net Listener — a process (implemented as a Windows service on Windows hosts) that runs on the database server and monitors the network for incoming connection requests. To access a database instance, such as the COIN instance, from a remote system, you must first tell the listener that instance exists. This is done by editing a file named listener.ora that sits on the database server.

Oracle Net also runs on client PCs that need to reach an Oracle database. Just as you tell the listener on the server about the databases it should accept connections for, you tell the Oracle Net client software on a PC about the databases it should be able to reach. To access COIN from a client computer, you need to tell the client that a COIN database exists, and point it to the server where the COIN listener resides. This is done by editing a file named tnsnames.ora that sits on the client PC — and it's worth adopting a predictable naming and distribution strategy for that file across your client machines from the start, then confirming each entry actually works with tnsping before relying on it. A later lesson, creating and maintaining tnsnames.ora, covers that in depth.

This course uses Local Naming — the tnsnames.ora approach just described — throughout, because it's straightforward and doesn't depend on any additional infrastructure. It's worth knowing it isn't the only option, though, since you'll run across the others in larger environments or in Oracle's own documentation:

• Directory Naming resolves connect identifiers against an LDAP-compliant directory server instead of a file on each client — useful when you need centralized management across many clients rather than a tnsnames.ora file copied everywhere. Oracle Internet Directory is one option for that directory server, alongside Oracle Unified Directory and Microsoft Active Directory; none of the three is required for anything covered in this course, and setting one up is its own separate topic.
• Centralized Configuration Provider naming resolves connect identifiers against a cloud-native configuration store — Azure App Configuration, or an OCI Object Storage bucket holding a JSON file, for example — rather than an LDAP directory or a local file.
• Easy Connect needs no configuration file at all for simple cases; the connection details go directly into the connect string. Modernized Easy Connect Plus extends this with additional connection options for 26ai and OCI-native connectivity, worth a look if you're working in a cloud-hosted environment rather than the on-premises style this course teaches. See Oracle 23ai/OCI service connection methods for more on that.

The COIN database you're working with in this course uses Local Naming exclusively — that's why the rest of this module focuses on listener.ora and tnsnames.ora rather than directory or cloud-based configuration.