Directory naming lets clients look up a connection name in a shared LDAP directory. The lookup supplies a connect descriptor: the listener address and database service that the client should request. This is useful when many clients need the same mapping and service locations change.
Oracle DBA Lesson 37A — How a Directory Alias Finds the Database
The client first resolves the name, then attempts a connection using the returned details. The listener routes the request, and the database establishes the session using its configured authentication rules. See the client-session sequence.
Follow the naming order
For an Oracle 19c Net/OCI client, NAMES.DIRECTORY_PATH in the selected sqlnet.ora profile controls naming-method order. Consider this explicit example:
NAMES.DIRECTORY_PATH = (TNSNAMES, LDAP, EZCONNECT)| Method | Source of connection information |
|---|---|
TNSNAMES | An entry in the client's selected tnsnames.ora file |
LDAP | A database service or net service name in the configured directory |
EZCONNECT | Host, optional port, and service supplied in an Easy Connect identifier |
This example places local naming first and LDAP second. Oracle's documented default has a different order: (tnsnames, ezconnect, ldap). Read the actual client profile when you investigate a connection. See sqlnet.ora parameters.
The same name can take two paths
Suppose the connection name is LABPDB_LAB and the intended destination is listener dbhost:1521, service labpdb.example.com.
| Starting condition | Resolution path with the example order |
|---|---|
| A valid local entry exists | TNSNAMES supplies its descriptor; the client attempts that destination. |
| The local entry is absent and LDAP lookup succeeds | The client tries LDAP, receives the directory descriptor, then attempts that destination. |
The name is the input to the lookup. The selected descriptor determines the connection destination. A stale local entry can therefore hide a corrected directory entry when local naming is first. If the local descriptor points to an obsolete address or service, investigate that selected mapping. Naming-method order governs resolution. Connection retries and failover are controlled by separate connection settings. A failure after successful resolution is not a promise that LDAP will supply a replacement descriptor.
The word alias is often used informally for a connection name. Oracle also defines a specific network service alias entry that references another directory object rather than containing its own descriptor. Microsoft Active Directory does not support that entry type. The example here uses LABPDB_LAB as a net service name, which avoids implying that every directory supports alias-entry indirection. See configuring naming methods.
Identify the directory dependencies
When the client uses an ldap.ora file, these fields explain where a lookup goes:
| Field | Meaning |
|---|---|
DIRECTORY_SERVERS | Host names and directory ports for primary and alternate directory servers |
DEFAULT_ADMIN_CONTEXT | Directory entry containing the Oracle Context used to locate connection names |
DIRECTORY_SERVER_TYPE | Directory type: oid for Oracle Internet Directory or ad for Microsoft Active Directory |
The directory endpoints are the lookup destination. The host and port in the returned connect descriptor identify the listener destination. Record which of these two endpoints a failed request was trying to reach.
Use the configuration selected by the actual client installation. Oracle documents directory-file locations and discovery behavior. A missing ldap.ora file can involve automatic discovery in a configured environment. The exercise below uses a supplied sanitized configuration and requires no file changes. See ldap.ora parameters and directory-resolution troubleshooting.
Directory access may itself use an authenticated LDAP bind under site policy. For example, Oracle documents wallet-based bind behavior for NAMES.LDAP_AUTHENTICATE_BIND. That directory-access step and authentication of COURSE_READER to Oracle Database are separate operations. Directory naming supplies destination information. Database authentication and authorization remain governed by the database's configured security system.
Locate the failing stage
| Evidence or condition | Interpretation and next check |
|---|---|
The configured name cannot be resolved to a descriptor, such as ORA-12154 | Check the actual naming order, name spelling and domain, selected files, directory reachability, and Oracle Context. The error alone does not establish that LDAP was the method attempted. |
| A descriptor is available but its listener endpoint is unreachable | Inspect the selected host, port, network path, and listener availability. |
A listener reports ORA-12514 | The request reached a listener, which does not know the requested service. Compare the descriptor's service with the intended service and listener registration. |
| Database login fails | Inspect the account and configured authentication conditions for that destination. |
A directory can return details for a destination that subsequently fails. Establish which source supplied the descriptor and which stage failed before changing configuration. See troubleshooting Oracle Net Services.
Use a direct connection as a comparison
In an authorized lab, a direct Easy Connect login to the same intended listener and service can help isolate the naming path:
sqlplus -L COURSE_READER@//dbhost:1521/labpdb.example.comSQL*Plus prompts for the password. Replace the example endpoint with the instructor's designated lab endpoint, and use an authorized account. -L prevents another username and password prompt if the initial connection fails. See the SQL*Plus LOGON option. Success establishes that this account can connect through that direct path at that time. If the named connection still fails, compare its resolved destination and lookup dependencies. The direct test leaves the central directory configuration unchanged. Differences in destination, security parameters, client, or test time affect the comparison.
tnsping LABPDB_LAB can also show how that client resolves the name and test listener reachability. A usable database login and the intended session destination require a database connection check. See testing connections.
Understand availability and cached information
An already established database session communicates over its existing database connection. A directory outage can affect new resolution requests while that session continues. Test a fresh connection with the relevant client, and record whether it actually requires a new lookup.
Descriptor caching depends on the client implementation and version. For example, Oracle's ODP.NET Managed Driver documentation describes resolving and caching LDAP aliases on demand. Its cache and connection-pool refresh procedures are specific to that driver. Do not apply them as universal OCI or SQL*Plus behavior. For the selected client, confirm supported caching, refresh rules, and lifetime before you explain an outage or a mapping change. See ODP.NET managed-driver configuration.
NAMES.LDAP_PERSISTENT_SESSION governs reuse of the LDAP connection after lookup. It is a directory-session setting. Do not treat it as a documented descriptor-cache lifetime. See sqlnet.ora parameters.
Oracle documents exporting directory entries to a local tnsnames.ora file for temporary use when a directory is unavailable. Manage such a copy with an owner, a review date, the selected naming order, and a verified destination. A local copy can become stale, and a local-first profile can continue selecting it after the directory has been corrected. Keep local overrides current, and review them when normal directory service returns. See configuring naming methods.
Practice: draw and diagnose the two paths
Use a supplied sanitized Oracle 19c naming configuration, or draw the example if LDAP is unavailable. You need read access to the selected client files for inspection. No directory server installation, directory edits, database changes, or service interruption is required.
- Record the client installation and naming-method order. Mark the roles of
sqlnet.ora,tnsnames.ora, and, if used,ldap.ora. - Draw the path for
LABPDB_LABwith a valid local entry. Then draw it with no local entry and a successful LDAP lookup. - Explain a stale local entry that resolves to an obsolete service. Identify the selected descriptor and the point where the destination can fail.
- Explain an unavailable directory when the local entry is absent. Identify the lookup dependencies to inspect.
- Explain what a successful direct Easy Connect login to the intended destination adds to the investigation. State what configuration still needs review.
- Explain how an existing session, a client-specific cache, and a managed local copy can affect observed availability.
Success means you can identify the selected naming source, distinguish resolution from connection and authentication, and justify the next check for each scenario. The diagram/read-only exercise has no cleanup. If the optional login is performed, exit the temporary SQL*Plus session. Any configuration revision requires separate authorization and a restoration plan for only the files changed.
Quiz
1. With (TNSNAMES, LDAP, EZCONNECT), a valid local LABPDB_LAB entry exists. Which source supplies the descriptor first?
2. The local entry is absent, and LDAP lookup succeeds. What does that lookup supply?
3. Does LDAP directory naming itself authenticate COURSE_READER to Oracle Database?
4. A stale local entry resolves successfully, and the connection reaches an obsolete destination. What should you inspect first?
5. A direct Easy Connect login to the intended service succeeds while the named connection fails. What is the useful conclusion?
All names and endpoints above are teaching examples. No Oracle connection or LDAP execution is represented as having been performed. Record the actual client and database version, the selected profile, the commands, the observed results, and the interpretation if you carry out the optional lab comparison.
No comments:
Post a Comment