Starting and Stopping the Directory Service (Directory Naming)

Oracle Names and the Names server were deprecated in Oracle 9i and are not part of Oracle AI Database 26ai. There is no namesctl process to start or stop.

Directory Naming replaces that model. Net service names and connect descriptors live in an LDAP-compliant directory. Name resolution works only while that directory service is up.

Supported directories in 26ai include:

• Oracle Internet Directory (OID), still supported but legacy for most new designs
• Oracle Unified Directory (OUD), the usual choice for new deployments
• Other LDAP directories such as Microsoft Active Directory or OpenLDAP, using the Oracle Net schema

What you operate is the directory itself, not a separate Oracle Names server.

The directory is the central store for:

1. Net service names
2. Database service entries
3. Network service aliases and connect descriptors

Oracle Net clients look those entries up with LDAP (or LDAPS). You can point clients at the directory with ldap.ora/sqlnet.ora, or pass LDAP details in the connect identifier so no local files are required.

1. Oracle Internet Directory or Oracle Unified Directory
   • Entries use Oracle object classes such as orclNetService, orclDbServer, and orclNetServiceAlias, under an Oracle Context (typically cn=OracleContext,...).
   • A client that connects as mydb issues an LDAP lookup and receives the connect descriptor.
   • Use NetCA's Directory Usage Configuration (or equivalent) to create ldap.ora.
   • Set DIRECTORY_SERVER_TYPE = OID for OID, OUD, or OpenLDAP.
2. Another LDAP directory (for example, Active Directory)
   • The directory must hold the Oracle Net schema. Active Directory uses DIRECTORY_SERVER_TYPE = AD.
   • Clients still use ldap.ora (host, port, SSL port, default admin context) or an inline ldap[s]://... connect string.
   • You may need extra schema or integration work. AD plus Centrally Managed Users is a separate, related path; Enterprise User Security is deprecated in 26ai.

Resolution path

1. The client has Directory Naming in NAMES.DIRECTORY_PATH, often after tnsnames and ezconnect.
2. The client reads ldap.ora or LDAP parameters in the connect identifier.
3. Oracle Net queries the directory for the net service name.
4. The directory returns the connect descriptor.
5. The client connects to the database with that descriptor.

Example ldap.ora

DIRECTORY_SERVERS = (ldapserver.example.com:389:636)
DEFAULT_ADMIN_CONTEXT = "dc=example,dc=com"
DIRECTORY_SERVER_TYPE = OID

Example inline connect identifier (no ldap.ora required)

ldaps://ldapserver.example.com:636/cn=sales,cn=OracleContext,dc=example,dc=com?DIRECTORY_SERVER_TYPE=oid

There is no Names control utility. Use the directory product's own tools.

• Start the directory first. OID, OUD, or the third-party LDAP server must be listening (LDAP and/or LDAPS) before clients can resolve names. Start it independently of the database, and keep it available for as long as clients need Directory Naming.
• Confirm it's reachable. Check host, port (389/636), TLS certificates, and that the Oracle Context exists. A down or unreachable directory looks like a naming failure on the client, not a database-down event. It's worth setting deliberate outbound, inbound, send, and receive timeouts in sqlnet.ora specifically for this scenario: without them, a client waiting on an unreachable directory can hang rather than fail with a clear, actionable error.
• Stop the directory only when you intend to stop name lookup. Unlike the old Names server, there's no required "stop the directory before stopping the database" rule. Databases can stay up; new connections that depend on LDAP simply can't resolve names until the directory returns.
• Optional authenticated binds. If anonymous LDAP binds are disabled, configure wallet-based or LDAPS simple authentication on the client (NAMES.LDAP_AUTHENTICATE_BIND, NAMES.LDAP_AUTHENTICATE_BIND_METHOD, client WALLET_LOCATION). That doesn't replace starting the directory; it only changes how clients bind to it.

# Conceptual replacement for the old namesctl start / namesctl stop
# Use the directory product's own service commands, for example:
#   systemctl start oud
#   systemctl status oud
#   systemctl stop oud
#
# Or the OID / OUD / AD admin consoles and CLI for that product.

Clients still need a running listener and database to complete the connection after the name is resolved. The directory only supplies the connect descriptor.

Worth walking through concretely, since knowing what a failure actually looks like before you're debugging it live beats reasoning about it in the abstract. Say the OUD instance backing Directory Naming goes down unexpectedly. Here's what does and doesn't happen:

• Sessions already connected keep working. The directory supplied a connect descriptor once, at connection time; it isn't consulted again for the life of that session.
• New connection attempts that rely on Directory Naming fail at the resolution step, before the client ever reaches the listener. With sane sqlnet.ora timeouts configured, that failure is fast and diagnosable; without them, it can hang instead.
• The database itself is completely unaffected. It has no dependency on the directory at all; it's purely a client-side resolution problem.
• Clients still holding a cached tnsnames.ora entry, if local naming is also in the search path as a fallback, can often connect anyway, which is exactly why keeping an exported local-naming fallback, mentioned earlier in this module, is worth the small maintenance cost for anything genuinely critical.

That asymmetry, existing sessions fine, new ones blocked, database untouched, is the single most useful thing to internalize from this lesson. It's also the cleanest illustration of why Directory Naming's dependency is real but bounded: it's a client connectivity problem, not a data availability problem, and treating it as the latter during an actual incident wastes time chasing the wrong system.

The next lesson concludes this module.