Overview of Directory Naming and Client Connections

Directory naming determines where to connect: it centrally stores Oracle Net connection information in an LDAP-compliant directory server. A client supplies a logical name, a net service name such as sales_app, and the directory returns a connect descriptor containing the listener address and destination database service. Administrators update that mapping centrally instead of distributing changes to every client's tnsnames.ora file. Net service names that were previously managed only in local tnsnames.ora files can be centralized this way, in Oracle Internet Directory, Oracle Unified Directory, or, with real limitations covered below, Microsoft Active Directory.

Client connection handling is a separate concern: it determines how the application actually establishes communication once directory naming has told it where to go. The two aren't linked, directory naming can resolve a service whose clients use dedicated servers, shared servers, or Database Resident Connection Pooling (DRCP); the naming method locates the destination, the connection model controls how Oracle services the work once it's there.

A lookup with directory naming proceeds as follows:

1. The client asks the directory to resolve the net service name.
2. The directory returns its connect descriptor.
3. The client uses that descriptor to contact the database listener.

The directory supplies connection information only; database authentication remains a separate step.

Most clients performing these lookups access the directory server^[1] using anonymous authentication. Directory servers usually allow this by default, though some, earlier releases of Oracle Internet Directory among them, require explicit configuration to permit anonymous access. To perform a lookup at all, a client first needs to find the directory server holding the relevant entry, which happens one of two ways:

1. Dynamically, using DNS. The directory server's location is stored and managed in a central domain name server; the client retrieves it from DNS at request time.
2. Statically, using ldap.ora. This file, created by Oracle Internet Directory Configuration Assistant and stored on the client host, records the directory server's location directly.

After a directory server is found, the client is directed to the Oracle Context, the realm from the root where Oracle-related entries live. A connect identifier resolved this way can be a database service, a network service name, or a network service alias, and each can be referenced by its common (relative) name if it lives in the default Oracle Context, or by a fully-qualified distinguished name if it doesn't.

Directory naming is one of several ways Oracle Net Services can resolve a connect identifier:

Naming method	Where connection information comes from
Directory naming	A centralized LDAP directory
Local naming	A client-accessible tnsnames.ora file
Easy Connect	A connection string specifying host, port, and service
Centralized Configuration Provider naming	A supported configuration provider, such as OCI Object Storage or Azure App Configuration

Directory naming is worth choosing specifically when many clients need centrally maintained service mappings; it does require an accessible directory service to be genuinely useful, which is overhead the other methods don't carry.

Once a client resolves where to connect, the listener decides how to actually handle the request. Oracle supports three principal models:

Model	How requests are handled	Resource implications
Dedicated server	A server process serves one client connection.	Each connection retains its own server resources.
Shared server	Dispatchers queue requests for a pool of shared server processes.	Multiple client sessions share server processes.
Database Resident Connection Pooling (DRCP)	Clients borrow and release pooled servers and associated sessions.	Database resources can be reused across application processes and hosts.

DRCP suits applications that acquire a connection, do a short unit of work, and release it; it complements application-side pools by enabling sharing across processes and hosts rather than replacing them. RMAN backup and recovery connections are a notable exception, they're expected to use dedicated servers.

Oracle introduced Directory Naming with Oracle9i in 2001, replacing the older Oracle Names method. The improvements were real and specific:

1. Standardization: LDAP is a standardized, widely supported protocol, unlike Oracle Names' proprietary approach.
2. Scalability: directory servers can be distributed and scaled for large environments in a way Oracle Names' flat-file approach couldn't match.
3. Flexibility: hierarchical naming structures and attributes for organizing network objects.
4. Centralized management: administration through directory servers rather than maintaining Names server state by hand.
5. Security: real authentication, authorization, and access control, rather than Oracle Names' limited options.
6. Integration: works alongside other LDAP-based directory services and applications.

Oracle Names was a distributed service meant to simplify setting up and administering Net8 clients and servers. Before it, propagating a tnsnames.ora file to hundreds of PC clients was the standard way to keep connection information current, and it still pays to adopt a predictable naming and distribution strategy and test with TNSPING if you're managing local naming files today. With Oracle Names, that request instead routed to a centralized Names server, which gathered the relevant connection details and passed them back to the requesting client.

In short, Oracle Names functioned much like a shared tnsnames.ora file on a network disk, and it had a corresponding weakness: a Names server failure could prevent clients from connecting at all, which is why Oracle allowed multiple Names servers to be defined for redundancy. Oracle Names has long since been deprecated in favor of Directory Naming, which uses LDAP-compliant directories, Oracle Internet Directory or Oracle Unified Directory today, for the same underlying job, with real redundancy built the same conceptual way: more than one directory server holding the same naming entries.

The diagram below shows that same redundancy concept applied to current, LDAP-based directory naming rather than the old Names server model. A client resolves a net service name, HR_APP in the example, against an LDAP directory service backed by two directory servers configured to replicate the same naming entries. If one directory server is unreachable, the client can use the alternate endpoint instead; both hold the entries needed to resolve the lookup. Once resolved, the returned connect descriptor, listener address and SERVICE_NAME, is what the client actually uses to reach the Oracle Net listener and establish a session with the database service.

Oracle Names offered an alternative to file-based tnsnames.ora resolution, where every client maintained its own copy. By keeping that information in a central Names server instead, Oracle Names reduced the effort of maintaining hundreds of individual tnsnames.ora files, eventually eliminating that maintenance entirely: whenever a registered server added a new database to its listener.ora file, Oracle Names picked up that information automatically and made it available to every registered client. The next lesson covers how a directory naming request actually gets resolved today.

[1]Directory Server: A directory server that is accessed with Lightweight Directory Access Protocol (LDAP). Support of LDAP-compliant directory servers provides a centralized method for managing and configuring a distributed Oracle network. The directory server can replace client-side and server-side localized tnsnames.ora files.