Oracle Net Services and Connectivity
This domain tests how a client finds and connects to a database: name resolution, listener registration, and the error codes that tell you which layer failed.
Name resolution and configuration files
The client resolves a connect identifier using the methods and order listed in NAMES.DIRECTORY_PATH in sqlnet.ora. Easy Connect embeds the host, port, and service in the connect string. Local naming uses tnsnames.ora, read from TNS_ADMIN or the Oracle home network/admin directory. Directory naming uses LDAP. On the server side, listener.ora defines listening endpoints and, optionally, a static SID_LIST. Dynamic service registration is performed by the instance through the LOCAL_LISTENER and SERVICE_NAMES parameters, so a database that starts after the listener still appears in lsnrctl services.
Dedicated and shared server
In dedicated server mode each connection gets its own server process. Shared server mode uses dispatchers configured by DISPATCHERS and server processes governed by SHARED_SERVERS and MAX_SHARED_SERVERS, with sessions queued through the SGA.
Worked example
tnsping ORCL succeeds, but SQL*Plus returns ORA-12514: TNS:listener does not currently know of service requested in connect descriptor. Reasoning: tnsping only proves that the name resolved and the listener answered, so the failure is at service lookup. The instance has not registered that service name or the descriptor names the wrong service. Check lsnrctl services for the actual service names, then verify SERVICE_NAMES and LOCAL_LISTENER on the instance.
Traps that cost marks
- Treating a successful tnsping as proof that authentication and service lookup will work.
- Mixing up ORA-12541 (no listener at the address) with ORA-12154 (the connect identifier could not be resolved).
- Expecting a listener restart to fix registration when the problem is a wrong LOCAL_LISTENER value on the instance.