Choosing the Right Naming Method

Question: is the centralized server model that Oracle Names used in Oracle8i still how Directory Naming works today?

No, not directly. The concept of centralizing naming information survived; the implementation is entirely different. Oracle Names grew out of the Net8 era, using a proprietary protocol and a dedicated server process, configured through its own names.ora file, separate from the client-side tnsnames.ora it was meant to reduce reliance on. It offered limited functionality, had real scalability limits, and was deprecated in Oracle 9i. Directory Naming replaced it as a resolution method: it uses the industry-standard LDAP protocol, supports dynamic service registration, and scales to multi-platform environments in a way Oracle Names never did. It's supported with Microsoft Active Directory too, though with real limitations worth knowing rather than assuming away: Windows-only on both client and server, a single Oracle Context instead of multiple, and no support for network service aliases.

The underlying object being resolved, a net service name, hasn't changed in concept. What changed is the method: a proprietary, single-purpose server replaced by a standard, general-purpose directory protocol.

Oracle's own documentation lays this out as a direct comparison across three naming methods, and it's specific enough to actually act on, not just a vague "it depends":

Naming method	Advantage	Disadvantage	Recommended for
Local Naming	Simple; resolves names across networks running different protocols	Requires local configuration on every client for every change	Small networks with a stable, infrequently-changing set of services
Directory Naming	One centralized update reaches every client; supports LDAP parameters directly in the connect identifier instead of external config files	Requires access to a directory server	Large, complex networks, Oracle's own figure is over 20 client computers, that change frequently
Centralized Configuration Provider Naming	Same centralization benefit, stored in a provider like OCI Object Storage or Azure App Configuration instead of LDAP	Requires access to that configuration provider	Same profile as Directory Naming, large networks with frequent change, when a cloud configuration store fits better than LDAP

That's a real, specific threshold, not a rule of thumb pulled from nowhere: past roughly 20 client machines with services that change often, the cost of updating every client's local configuration by hand starts to outweigh the cost of running a centralized directory.

Made concrete: a ten-person development shop with two databases that haven't changed hosts in a year is squarely in Local Naming territory, updating two tnsnames.ora entries by hand, on the rare occasion they change, costs nothing. A 200-client sales organization adding and retiring database services every quarter is the opposite case; hand-editing 200 local files for every change isn't just tedious, it's the kind of process that reliably produces stale, inconsistent client configurations. That's exactly the gap Directory Naming closes.

Beyond the client-count threshold, a few more specific signals point toward Directory Naming:

• You want one authoritative catalog of database services, net service names, and aliases, rather than that information scattered across every client.
• You need net service aliases, including an alias defined in one Oracle Context that points to a service defined in a different Context, useful for multi-domain or multi-region setups.
• You already run an LDAP directory for other purposes and want Oracle Net to use that same infrastructure rather than standing up something separate.
• You want to migrate existing tnsnames.ora entries into the directory and manage them centrally going forward, worth pairing with a predictable naming and distribution strategy, tested with TNSPING, for whatever local entries remain in the mix during and after that migration.

And a few signals that point the other way, toward Local Naming or Easy Connect instead:

• A small or simple network with few, stable services, the administrative overhead of Directory Naming isn't buying you much there.
• No directory server, and no appetite to operate one. That's the real disadvantage Oracle's own table lists, and it's not a small one: once clients depend on the directory to connect at all, its availability becomes your availability. This module's earlier lesson on redundant LDAP servers exists specifically to address that, running more than one directory server holding the same entries so a single server going down doesn't take connectivity with it, but that redundancy is itself more infrastructure to plan for and operate, part of the real cost this decision involves, not something that comes free once you've decided to centralize.
• Clients that can't reliably reach LDAP, an unreliable network undermines the whole point of centralizing resolution.
• A cloud-centric setup where a configuration provider like Azure App Configuration or OCI Object Storage fits your existing operations better than standing up LDAP, Centralized Configuration Provider Naming covers that case specifically.

Two configuration details worth knowing once you've decided Directory Naming fits. First, if you want it to be a client's primary method, put it first in the search order:

NAMES.DIRECTORY_PATH=(ldap, tnsnames, ezconnect)

Order matters here beyond just precedence: each method in the list gets tried in sequence until one resolves the name, so putting a slower, network-dependent method like LDAP after a fast local check can mean paying that local lookup's cost on every single connection attempt, even when you know directory naming is what's actually going to succeed. Listing it first for an environment where it's the primary method avoids that unnecessary detour. Second, 26ai clients don't strictly need ldap.ora and sqlnet.ora configured at all; LDAP lookup parameters can be passed directly in the connect identifier itself:

ldap[s]://host[:port]/name[,context][?parameter1=value1&parameter2=value2]

If both the connect-identifier parameters and the external configuration files exist, the connect-identifier values take precedence. Once configured, a client whose default directory entry matches the service location can connect with a plain CONNECT username@connect_identifier; otherwise it needs the entry's distinguished name or fully qualified name instead.

The bottom line hasn't really changed from the underlying logic that made centralized naming worth considering decades ago, it's just applied to a real, current choice now: use Directory Naming when centralized LDAP administration is worth taking on a directory dependency, especially in large, frequently-changing networks. Use Easy Connect or Local Naming when the environment is small and stable enough that the overhead isn't worth it.