Storing Network Configuration on the Local Filesystem

Question: which files actually store Oracle Net's configuration on a host's local filesystem?

Four files, each with a distinct job, together represent the local view of network topology for that computer:

• tnsnames.ora, net service names mapped to connect descriptors, the map of how a client reaches a service; worth pairing with a predictable naming and distribution strategy, tested with TNSPING, so entries stay consistent across every host that has a copy.
• sqlnet.ora, naming method order, domains, tracing, security, and timeout parameters, covered in more depth in an earlier lesson this module.
• listener.ora, the listener's own endpoints and the services it advertises, configured server-side.
• cman.ora, Oracle Connection Manager settings, present only where Connection Manager is actually in use.

It's worth being precise about the split between the first two, since they're easy to conflate: tnsnames.ora is about where to find a service; sqlnet.ora is about how the connection process itself behaves. Neither one configures the listener's own port or endpoints, that's listener.ora's job specifically.

A few related files worth knowing exist, without overstating their scope: ldap.ora is a directory server usage file, recording where a client can statically find a directory server for LDAP-based lookups, not a configuration file for directory products themselves. oraaccess.xml is a separate, client-side file for configuring selected OCI parameters, statement caching and FAN event handling among them, unrelated to network topology storage.

Tools like the Oracle Net Configuration Assistant (netca) and DBCA write these files to predictable defaults:

• Database home: ORACLE_HOME/network/admin
• Grid Infrastructure home: GRID_HOME/network/admin
• Read-only Oracle home: ORACLE_BASE_HOME/network/admin

The TNS_ADMIN environment variable overrides all of these, and is checked first. On Linux and UNIX, the search order after TNS_ADMIN falls back to the home's own network/admin directory, with an additional fallback to ORACLE_HOME/network/admin for read-only homes.

1. Run the Oracle Net Configuration Assistant (netca) from the 26ai Oracle home or Grid home.
2. Select Local Naming (or listener configuration) and define the service names, SCAN addresses, VIPs, or Connection Manager entries you actually need.
3. Confirm or explicitly set TNS_ADMIN if you want a non-default directory.
4. Place copies of the generated files on every client and server that should use this local topology.
5. In sqlnet.ora, set NAMES.DIRECTORY_PATH = (TNSNAMES, EZCONNECT), or whatever order fits your environment, so local files are consulted in the order you actually want.

For a RAC or Grid cluster, these same files live in the Grid home, but Clusterware itself stores interface classification, public, cluster interconnect, ASM, in the OCR through oifcfg, not in these local text files. That's a genuinely separate configuration layer from what this lesson covers.

Once these files exist on the local filesystem, clients and listeners use that stored topology directly, no central directory or LDAP lookup required. The trade-off is the one this module keeps returning to: changes require updating the files on every host individually, or distributing updated copies, exactly the maintenance burden Directory Naming exists to remove once an environment outgrows it.

Worth knowing which file to actually check when something's wrong, since that's usually the real question: a client that can't find a service at all points to tnsnames.ora, missing or mistyped entry, wrong TNS_ADMIN, or a naming method search order in sqlnet.ora that never reaches local naming in the first place. A client that finds the entry but the connection hangs or times out points to sqlnet.ora's timeout settings instead. A connection that reaches the right host but gets refused points to listener.ora, wrong port, service not registered, listener not running at all. Keeping straight which file actually owns which piece of the picture is most of what separates a fast diagnosis from a slow one.

Worth knowing this existed, without treating it as something to configure today: Oracle Names used its own dedicated file, names.ora, on each Names server, alongside client-side sqlnet.ora parameters like names.preferred_servers and names.default_domain pointing clients at that server. A real names.ora file ran to dozens of parameters, connection details, caching, logging, trace settings, region administration, and, notably, an administrative password stored in plain text directly in the file. That's a real security weakness, the same broad pattern this module has already flagged with Oracle Names' handling of credentials, just a different specific instance of it here: an admin password for the server itself, sitting unencrypted in a config file anyone with file access could read.

Here's what that actually looked like in practice, a genuine excerpt from a real names.ora file:

names.server_name = dilbert.world
names.admin_region = (region=
    (name=local_region.world) (type=rosdb)
    (userid=namemgr) (password=namepass)
    ...)
names.password = secret_passwd

Two separate plaintext passwords in one configuration file, one for the administrative region, one for the server itself. Neither was encrypted, hashed, or protected beyond ordinary filesystem permissions.

None of that configuration exists in Directory Naming. There's no local, dedicated server process to configure, no equivalent plaintext-password file, because the whole point of moving to a standard directory protocol was retiring exactly this kind of purpose-built, self-contained configuration in favor of infrastructure built for it. Whatever authentication a directory server requires for administrative operations is handled through that directory product's own, generally more robust, security model, not a flat text parameter sitting next to caching and logging settings.

Before moving on, click the Quiz link below to check your understanding.
Oracle Names Concepts - Quiz