Oracle Net Parameter Files

Oracle Net Services is configured through a set of plain-text parameter files that govern how clients locate database services, how connections are secured, how the listener accepts incoming requests, and how network activity is logged and traced. Understanding the syntax and function of these files is fundamental to Oracle network administration — GUI tools such as Oracle Net Manager and Oracle Net Configuration Assistant are front ends that write to these same files, and many experienced administrators prefer to edit them directly. In large or complex environments, direct file editing is often the only practical approach.

The parameter files are located in $ORACLE_HOME/network/admin by default. Their location can be overridden through the TNS_ADMIN environment variable, which allows multiple Oracle homes or client installations to use separate configuration directories. In Oracle 23ai, centralized configuration providers can replace file-based naming entirely for cloud deployments, but the file-based approach remains fully supported and is the baseline for on-premises and hybrid environments.

sqlnet.ora

The sqlnet.ora file is the primary profile configuration file for Oracle Net Services. It applies to both clients and servers and controls a wide range of network behaviors including naming resolution order, authentication methods, encryption settings, tracing, logging, and connection timeout parameters.

The NAMES.DIRECTORY_PATH parameter specifies the order in which Oracle Net tries naming methods when resolving a service name. A typical on-premises configuration tries local tnsnames.ora first, then LDAP directory naming:

NAMES.DIRECTORY_PATH = (TNSNAMES, LDAP)

Timeout parameters in sqlnet.ora prevent hung connections in distributed environments. The most important are SQLNET.INBOUND_CONNECT_TIMEOUT, which limits how long the listener waits for a client to complete authentication after the connection is accepted, and SQLNET.EXPIRE_TIME, which sends periodic keepalive probes to detect dead client connections:

SQLNET.INBOUND_CONNECT_TIMEOUT = 60
SQLNET.OUTBOUND_CONNECT_TIMEOUT = 30
SQLNET.EXPIRE_TIME = 10

The SQLNET.CLIENT_REGISTRATION parameter assigns a unique identifier to a client host. This identifier is passed to the listener with every connection request and is recorded in the audit trail, which is useful for tracing connection activity back to a specific workstation in environments where multiple clients share a database account:

SQLNET.CLIENT_REGISTRATION = 1432

The identifier can be any alphanumeric string up to 128 characters. The default is none.

For encrypted connections, sqlnet.ora specifies the acceptable encryption algorithms and the encryption mode. Oracle 23ai supports TLS 1.3 for TCPS connections, and native network encryption through the SQLNET.ENCRYPTION_SERVER and SQLNET.ENCRYPTION_TYPES_SERVER parameters for TCP connections where TLS is not used.

tnsnames.ora

The tnsnames.ora file maps network service names — also called TNS aliases — to connect descriptors. A connect descriptor specifies the protocol, host, port, and service name required to reach a database instance. Client applications reference the service name rather than embedding connection details directly in application code, which allows connection targets to change without requiring application modifications.

A typical tnsnames.ora entry has the following structure:

ORCL =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = dbserver.example.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl.example.com)
    )
  )

The service name at the top (ORCL) is the alias the client uses in its connect string. The SERVICE_NAME inside CONNECT_DATA is the database service registered with the listener. These two values are independent — the alias can differ from the service name, which allows multiple aliases to point to the same database service or to different services on the same host.

In large environments, distributing and maintaining tnsnames.ora files across many client hosts introduces operational overhead. Oracle addresses this through LDAP directory naming, which stores connect descriptors centrally in an LDAP server, and through the Centralized Configuration Provider feature in Oracle 23ai, which stores descriptors in OCI Object Storage or Azure App Configuration. Both approaches allow a single update to propagate to all clients without file distribution.

For environments that retain local tnsnames.ora files, adopting a predictable naming convention and validating entries with tnsping before deploying changes reduces connectivity failures caused by syntax errors or stale entries.

listener.ora

The listener.ora file configures the Oracle Net Listener on the server side. It specifies the protocols and addresses the listener monitors, the database instances and services it registers statically, and connection rate limits. A minimal listener.ora entry defines the listener name and its listening address:

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = dbserver.example.com)(PORT = 1521))
    )
  )

In Oracle 10g and later, database instances register their services with the listener dynamically through the LREG background process, which means static SID_LIST_LISTENER entries in listener.ora are only required for older clients that use SID-based connections rather than service name-based connections, or for external procedure dispatchers and Oracle pre-spawned server processes.

The listener is managed through the lsnrctl command-line utility. Common operations include lsnrctl start, lsnrctl stop, lsnrctl status, and lsnrctl reload to apply configuration changes without stopping and restarting the listener. Oracle 23ai adds a PING command to SQL*Plus that tests listener connectivity directly without requiring a separate tnsping invocation.

protocol.ora

The protocol.ora file configures protocol-specific parameters for Oracle Net network communication. It is optional in most deployments and is not required for standard TCP/IP or TCPS configurations. Its presence is most common in environments with firewall traversal requirements, specific buffer size tuning needs, or protocol restriction policies that cannot be addressed through sqlnet.ora alone. For the majority of Oracle installations, protocol.ora is absent and the defaults are sufficient.

Oracle Connection Manager and cmctl

Oracle Connection Manager (CMAN) is a lightweight session multiplexor and access control filter that sits between clients and the database listener. It can reduce the number of direct connections to the database by multiplexing multiple client sessions over fewer server connections, apply connection access rules based on source host or service name, and perform protocol conversion in heterogeneous network environments. CMAN is administered through the cmctl command-line utility.

In modern OCI deployments, the functions that CMAN provided on-premises are largely handled by cloud infrastructure components. The following table summarizes the correspondence:

CMAN and cmctl remain available and supported in Oracle 23ai for on-premises and hybrid deployments where cloud-native alternatives are not yet in place. For new OCI deployments, VCN configuration, Security Lists, Network Security Groups, and the OCI Bastion Service are the recommended tools for the functions that CMAN provided.

Direct File Editing vs. GUI Tools

Oracle Net Manager and Oracle Net Configuration Assistant provide graphical interfaces for configuring the Net parameter files. Both tools write to the same tnsnames.ora, listener.ora, and sqlnet.ora files that direct editing produces. In small environments they reduce the risk of syntax errors. In large Oracle installations — particularly those running a mix of Oracle versions, multiple listeners, or non-standard directory structures — direct file editing gives administrators full control and avoids the limitations and occasional destructive behavior of GUI tools that reformat or reorder existing entries.

Any computer running Oracle software can act as a Net client, a Net server, or both simultaneously. Creating a functional Net server requires installing Oracle Database, creating a listener.ora file, and starting the listener with lsnrctl start. Once the listener is running and the database instance has registered its services, clients can connect using a TNS service name, an Easy Connect string, or a wallet-based connection descriptor for Autonomous Database.

The next lesson examines the components of Oracle Network Services in detail, covering how the listener, TNS protocol, and naming methods work together to establish and maintain client-to-database connections.