Oracle 26ai Net Connections at the Process Level

An Oracle connection involves more than a host name and a listening port. A client must resolve its destination, reach an appropriate listener when the connection requires one, request a database service, and establish a session served by Oracle database code. Understanding these stages helps you distinguish a naming problem from a listener problem, an unavailable service, or an authentication failure.

This lesson follows an ordinary dedicated-server connection in Oracle AI Database 26ai, contrasts it with local and shared-server connections, and shows how to inspect the resulting session. The examples assume an existing single-instance database, a running listener, a registered application service, and an authorized application account. Replace the example host, service, alias, and user names with values supplied by your DBA. Commands are instructional examples, not results from a particular installation.

Identify the processes involved

Separate connection establishment from database traffic

A listener-mediated connection begins when the client sends a request containing a service name. The listener uses its knowledge of available service handlers to arrange the connection. Depending on the operating system, transport, and configuration, this can involve handing off the connection or redirecting the client to a handler's address.

After an ordinary dedicated-server connection is established, the client exchanges database requests with its server process. The listener is not a relay through which every SQL statement and result must pass. This distinction explains why a successful listener status check does not establish that an application query will succeed. It also explains why diagnosing an already established session is different from diagnosing a new connection attempt.

The exact process-creation mechanism can vary. Oracle 26ai can use a dedicated connection broker in applicable configurations, so avoid assuming that the listener always directly creates the server execution entity. For the basic workflow, focus on the observable stages: requested service, available handler, successful login, and resulting session. Oracle describes the connection-handling alternatives in its database service connection documentation.

Compare TCP, local IPC, and bequeath

TCP supports connections across a network and can also connect processes on the same host through a loopback address. A client using localhost refers to its own machine. Consequently, an alias containing localhost that works on the database server does not automatically work from a workstation.

IPC, or interprocess communication, provides a local transport. A listener-mediated IPC connection uses a configured IPC endpoint and a matching key in the client's connect descriptor. It does not carry a connection between separate computers. Treat matching keys as endpoint configuration, not as a substitute for database authentication or an assurance that a connection is authorized.

Bequeath provides a different local connection path. A same-host client can establish a dedicated-server connection without going through the listener. It remains documented in Oracle 26ai; it is not generally deprecated merely because TCP and IPC are available. Its use depends on the client, operating system, environment, and database configuration. Local administrative authentication additionally requires the applicable privileges and authentication setup.

These alternatives support different connection requirements. A working local bequeath connection does not prove that a remote TCP endpoint is reachable. Conversely, successful application access over TCP does not demonstrate that a local administrative connection is configured. Test the path that the application actually uses. Oracle's process architecture documentation explains the distinction between client and server execution.

Inspect the actual listener and its services

On the server, use the appropriate Oracle software environment and an account authorized to inspect the listener. Specify its name rather than assuming that every installation uses the default name:

lsnrctl status LISTENER
lsnrctl services LISTENER

In the STATUS output, examine Listening Endpoints Summary for the active protocol addresses. TCP port 1521 is a common default, but installations can use another port or several endpoints. Also inspect the listener alias and reported configuration-file location. These details help detect a command run from the wrong Oracle home or directed at the wrong listener.

SERVICES provides details about the services, instances, and handlers known to that listener. Look for the exact service requested by the application. An endpoint can be listening while the required service is absent. Dynamic service registration, performed by LREG, normally supplies database service information; an ordinary application service does not require an unrelated external-procedure static registration.

Keep complete diagnostic output when investigating a failure. Extracting the first occurrence of PORT can accidentally report the address used for the administrative connection and overlook additional listening endpoints. The Listener Control Utility reference describes the commands and their output.

Inspection is the appropriate first action. Do not restart a listener simply because a client cannot log in. Establish ownership and management context before making changes, particularly when Oracle Grid Infrastructure manages the listener. A restart can obscure useful evidence without correcting the client alias or requested service.

Keep the configuration files in their proper roles

The preceding lesson introduced the profile. For example, this entry selects an illustrative naming-method order:

NAMES.DIRECTORY_PATH=(EZCONNECT,TNSNAMES)

That entry does not create a listener or register a database service. It tells a compatible client how to attempt name resolution. Oracle Net Configuration Assistant can establish initial configuration, while Oracle Net Manager provides profile editing. The profile configuration guide explains these responsibilities.

Determine which files the particular client or server process reads. Check its TNS_ADMIN setting and Oracle home context. Read-only Oracle homes can use ORACLE_BASE_HOME/network/admin; other configurations commonly use the Oracle home's network/admin directory. Platform and client differences matter. An interactive shell and a scheduled application can inherit different environments, even when the same person configured both.

This is why editing a familiar file is not sufficient evidence of a fix. Record the executable, environment, and destination used by the failing application, then repeat the connection from that context. Do not change every copy of a configuration file on the host in the hope that one is active.

Connect to an existing application service

The following alias requests the example service apppdb.example.com through TCP and explicitly requests a dedicated server. It assumes that the listener already advertises that service:

APPDB =
  (DESCRIPTION =
    (ADDRESS =
      (PROTOCOL = TCP)
      (HOST = dbhost.example.com)
      (PORT = 1521)
    )
    (CONNECT_DATA =
      (SERVICE_NAME = apppdb.example.com)
      (SERVER = DEDICATED)
    )
  )

Place the entry in the tnsnames.ora file used by the test client. Connect with SQL*Plus and enter the password when prompted:

sqlplus app_user@APPDB

An Easy Connect string can instead specify the host, port, and service directly:

sqlplus app_user@//dbhost.example.com:1521/apppdb.example.com

This second form helps compare explicit destination details with alias resolution. It does not include the alias's explicit dedicated-server request, so use the APPDB example when testing that exact server-mode selection. Neither form requires putting a password in command history.

A naming test is useful, but tnsping does not authenticate the account or prove that a database session can execute SQL. After login, verify the application has reached its intended service and container through approved application checks. A successful connection to the wrong service is still a configuration error.

Transport security is a separate concern. TCP alone does not establish whether encryption has been configured. Use the organization's approved TLS/TCPS or native network encryption configuration as applicable. Changing a port number is not an encryption measure, and this connection example should not be treated as a complete security configuration.

Inspect the resulting dedicated sessions

SELECT s.sid,
       s.serial#,
       s.con_id,
       s.username,
       s.service_name,
       s.server,
       s.machine,
       s.osuser,
       s.process AS client_process,
       p.spid AS server_os_pid,
       p.stid AS server_os_tid,
       s.program
FROM v$session s
LEFT JOIN v$process p ON p.addr = s.paddr
WHERE s.type = 'USER'
  AND s.server = 'DEDICATED'
ORDER BY s.sid;

Compare observations before and after a test connection

A useful lab exercise uses two sessions: an application connection under test and an authorized monitoring session. First record the intended alias and service. Open the application connection, keep it available, and ask the monitoring session to inspect the dedicated-session query. Identify the application row using several attributes together rather than assuming it is the newest or highest-numbered SID.

Next, disconnect the application normally and inspect again. The row should no longer represent an active application connection, although cleanup timing and other activity can affect what you observe. Repeat the test and compare the identifiers. Do not expect the new session to retain the previous SID, serial number, or server process identifier. The purpose is to connect a deliberate client action with database evidence, not to memorize a particular listing.

If the expected row is absent, first examine the test assumptions. Was the connection dedicated? Is the monitoring account looking at the correct instance and container? Did the application disconnect immediately? Does the monitor have sufficient visibility? These questions are more useful than changing the join until an unrelated row appears. A filtered diagnostic query can correctly return no rows when its assumptions do not match the connection.

Keep credentials out of the lab record. Save the connection destination, timestamps, error text, and relevant identifiers instead. This produces a small, reproducible case that another DBA can examine without needing the application's password or an unexplained screenshot of an entire process list.

Recognize shared server and threaded execution

Shared server, historically called Multi-Threaded Server or MTS, remains an Oracle architecture. Clients connect through dispatchers, and shared servers process queued requests. A session does not have a permanently assigned dedicated server in the same way as the dedicated example above. Oracle documents this design in Configuring a Shared Server Architecture.

Threaded execution concerns how Oracle execution entities map to operating-system processes and threads. It is a different concept from sharing servers among sessions. Avoid using an operating-system process count as a direct user-session count, or declaring shared server unavailable because a familiar process listing looks different. Choose observations appropriate to the actual architecture.

Use a repeatable troubleshooting sequence

1. Confirm the intended destination. Record the client alias or explicit connect string, host, port, and application service.
2. Confirm the client's configuration context. Identify the client executable and relevant environment before changing files.
3. Inspect the listener. Read its active endpoints and services rather than relying on a remembered default.
4. Attempt an authorized login. Record the exact error and timestamp. Successful name resolution does not complete this test.
5. Inspect the session. Use an appropriately privileged account to verify service, server mode, and process association.

For example, if an explicit host-and-service connection works but APPDB fails, compare alias resolution before modifying the server. If both reach a listener that lacks the service, investigate service availability and registration. If the login fails after reaching the requested service, examine the reported authentication or account condition. These observations narrow the next step without treating every failure as a listener restart problem.

The next lesson applies this connection model to Oracle database links. A database session can initiate access to another database, making the originating database a client for that connection. The same distinctions between destination naming, listener endpoints, services, and authentication remain useful.