Lesson 1

To be useful, a database must be reachable from computers other than the one it lives on. Oracle supplies Oracle Net Services for exactly this purpose — the terms "Oracle Net Services" and the older name "SQL*Net" refer to the same thing throughout Oracle's documentation, so don't be thrown off if you run across "SQL*Net" in older material. This module walks through configuring Oracle Net so you can connect to your COIN instance from any computer running Oracle client software.

Oracle Net itself is made up of two pieces working together: a listener, and Oracle's protocol support layer. Together, they let client software talk to an Oracle database using whatever networking protocol the underlying environment actually provides — TCP/IP most commonly, but not exclusively. Oracle Net exists specifically to give client applications one consistent interface, regardless of which protocol is doing the actual carrying underneath. A client application written against Oracle Net doesn't need to know or care which protocol is in play; Oracle Net handles that translation on its behalf.

You'll learn about the three key Oracle Net configuration files in this module:

1. listener.ora
2. tnsnames.ora
3. sqlnet.ora

You'll also learn about the listener control program — how to use it to start and stop the listener and check its status — and how to use Oracle's client-side configuration tools so a client PC recognizes, and can connect to, your COIN database.

1. Oracle Net: Oracle's networking component, used to connect a client application to a database server, or to connect two databases to each other. Oracle Net insulates both the database and client applications from the specifics of whichever underlying network protocol is actually being used.
2. Listener: A process that runs on the database server and listens for incoming connection requests from clients wanting to reach a database on that server.
3. Protocol support layer: The part of Oracle Net that adapts its own internal communication to a specific underlying networking protocol — for example, the TCP/IP protocol support handles running Oracle Net over a TCP/IP network. This is a software component inside Oracle Net itself, not a piece of physical hardware; it has nothing to do with the network interface card in your machine, which is a separate, unrelated layer of the network stack entirely.
4. TCP/IP: The standard communication protocol for client/server connectivity, and the one this course focuses on throughout.
5. TCP/IP with TLS: TCP/IP with Transport Layer Security added, encrypting the connection between an Oracle application and the database.
6. Named Pipes, Sockets Direct Protocol (SDP), Exadirect, and WebSocket: The remaining protocols Oracle Net currently supports, each suited to a specific environment — Named Pipes for certain Windows configurations, SDP and Exadirect for high-performance interconnects, and WebSocket for browser-based connectivity. You won't need most of these for a typical COIN setup, but it's worth knowing they exist rather than assuming TCP/IP is the only option.

It helps to walk through what actually happens, piece by piece, when client software connects to an Oracle database over a network:

The Listener

• The listener is a process running on the server machine where the Oracle database lives.
• It listens for incoming connection requests, arriving over whichever protocol Oracle Net has been configured to support — TCP/IP, in most environments.
• When a request comes in, the listener establishes the connection and hands it off to the appropriate database instance.

The Protocol Support Layer

• This is the piece of Oracle Net that adapts its communication to whichever specific network protocol is actually carrying the traffic.
• It's what lets the exact same client application work identically whether it's running over TCP/IP, TCP/IP with TLS, or one of Oracle's other supported protocols — the application code itself never needs to change.
• It operates entirely in software, on both the client and server sides. It's a logically separate concern from the physical network interface card that actually puts bits on the wire — that's a lower layer of networking Oracle Net doesn't need to know or care about.

Client Software Communication

• Client software — SQL Developer, SQL*Plus, or any other Oracle client tool — initiates a connection by specifying the server's hostname or IP address and the port the listener is running on.
• The client sends a connection request to the listener, using whichever protocol Oracle Net's protocol support layer has configured for that session.
• The listener receives the request and forwards it to the correct database instance, based on the service name in the connection string.
• Once connected, the client can send SQL statements and receive results back, for the life of the session.

In short: the listener acts as a gatekeeper, directing incoming connection requests to the right database instance. The protocol support layer is what makes that gatekeeping work the same way no matter which underlying network protocol a particular client happens to be using.

Three files do most of the work in this module:

• listener.ora — configures the listener itself: which addresses and ports it listens on, and which database services it's aware of.
• tnsnames.ora — maps a friendly service name (like COIN) to the actual connection details a client needs — host, port, and service. Getting this file's naming and distribution strategy right across multiple client machines matters more than it might seem at first; a later lesson covers creating and maintaining tnsnames.ora in depth, including how to test a new entry with the tnsping utility before relying on it.
• sqlnet.ora — controls network-level behavior for Oracle Net generally, including timeout settings. Sane inbound, outbound, send, and receive timeout values are worth setting deliberately rather than leaving at their defaults, since misconfigured timeouts are a common cause of connections that hang instead of failing cleanly. That's covered in detail in a later lesson on setting TNS timeout values.

Two distinct Oracle-supplied tools handle Oracle Net configuration, and they're not interchangeable:

• Oracle Net Configuration Assistant (NETCA) runs automatically during Oracle software installation, and can also be run standalone afterward for basic network component setup. It's the tool oriented toward initial, guided configuration.
• Oracle Net Manager is the graphical tool for ongoing, fine-grained configuration of Oracle Net components within a specific Oracle home — the one you'll reach for when you need to edit configuration details directly rather than walk through a guided setup.

Later in this module, you'll use one or both of these to configure a client machine so it recognizes and can connect to your COIN database.

The listener control utility (lsnrctl) is what you'll use throughout this module to start the listener, stop it, and check its current status. That remains true for the single-instance environment this course works with. One thing worth knowing as you go further in your Oracle career, even though it's outside this module's scope: in a Real Application Clusters (RAC) or Grid Infrastructure environment, Oracle recommends using the SRVCTL utility instead of lsnrctl to start and stop the listener, so that Oracle Clusterware's own view of the listener's state stays in sync. For the COIN instance you're working with here, lsnrctl is exactly the right tool.

Two commands you'll use repeatedly in this module, for two different purposes:

• ping confirms basic network reachability to the host — it tells you whether the machine is up and responding at the network level at all, with no knowledge of Oracle whatsoever.
• tnsping goes a level deeper: it confirms whether the Oracle Net listener specifically is reachable and responding for a given service name, using the connection details defined in tnsnames.ora. A successful ping with a failing tnsping usually points you straight at a listener or tnsnames.ora configuration problem, rather than a network problem.

By the end of this module, you will be able to:

1. Edit the listener.ora file, and add an entry for another database instance
2. Edit the tnsnames.ora file, and add a new service name for use by client software
3. Use the ping command to verify basic connectivity to the host
4. Use the tnsping command to verify connectivity to the Oracle Net listener specifically
5. Start and stop the Oracle Net listener
6. Connect to a remote database over the network