Turn On Logging and Tracing for Network Services

In earlier Oracle releases the focus of this lesson was Net8 and SQL*Net. Today, in Oracle Database 26ai, the same concepts live on under the name Oracle Net Services; both of those older names describe the same underlying facility, now folded into current connection methods such as Easy Connect Plus and OCI-native connections, see Oracle 23ai OCI Service Connection Methods for the current approach. Logging and tracing are still available, but you typically enable them only when you are troubleshooting or working with Oracle Support, not as a permanent setting.

The goal of this lesson is to show how Oracle Net logging and tracing work, explain why they were essential in the Net8 era, and then place those skills in a modern context that includes Oracle 26ai features such as Easy Connect Plus, TLS 1.3, and the Automatic Diagnostic Repository (ADR).

Oracle Net produces two main kinds of diagnostic output:

• Logging: high-level summaries of events (startup, shutdown, connection attempts, errors) written to listener and client/server log files. This is on by default, through ADR.
• Tracing: detailed, step-by-step records of Oracle Net internal operations, used to diagnose problems such as connectivity failures, timeouts, TLS handshake issues, and intermittent disconnects. This is off by default.

Tracing produces more volume and overhead than logging, so you normally enable tracing at higher levels only for short, targeted diagnostic sessions.

In the original version of this lesson, you enabled tracing by editing listener.ora and sqlnet.ora, or by using Enterprise Manager's component controls. Those files are still used in Oracle 26ai, but the terminology has shifted from "Net8" to "Oracle Net Services."

Some key ideas from the historical material remain useful:

1. Server-side trace files were stored under $ORACLE_HOME/network/trace and controlled by parameters in listener.ora, such as TRACE_LEVEL_*, TRACE_DIRECTORY_*, and TRACE_FILE_*.
2. Client-side trace files were controlled in sqlnet.ora with parameters such as TRACE_LEVEL_CLIENT, TRACE_DIRECTORY_CLIENT, TRACE_FILE_CLIENT, and TRACE_UNIQUE_CLIENT.

For example, a typical client tracing configuration in the Net8 era looked like this:

TRACE_LEVEL_CLIENT=SUPPORT
TRACE_DIRECTORY_CLIENT=/tmp/client_traces
TRACE_FILE_CLIENT=netcli.trc
TRACE_UNIQUE_CLIENT=ON
TRACE_TIMESTAMP_CLIENT=ON

These settings are still valid in 26ai, but they are now part of a broader diagnostics stack that includes ADR and cloud-centric logging.

Yes, but only selectively. In Oracle 26ai you rarely turn on detailed Oracle Net tracing by default. Instead:

• You rely on standard logs and ADR for routine monitoring, because the database and listener automatically write diagnostic information into the ADR directory structure.
• You enable Oracle Net tracing only when you are tracking down a stubborn connection issue, debugging TLS configuration problems, or collecting data requested by Oracle Support.
• In Oracle Cloud and OCI environments, you often combine Oracle Net tracing with OCI Logging and Metrics so that network-level issues are correlated with host and database metrics.

So the skill is still relevant, but the default posture in 26ai is: keep tracing off until you need it, then enable it temporarily with clearly defined scope and retention.

The mechanics of enabling tracing are essentially unchanged from the Net8 era, but you should think about them in the context of Easy Connect Plus, TLS, and ADR:

• Easy Connect Plus simplifies connection strings and can remove the need for tnsnames.ora for many common use cases, since protocol, host, port, service name, and several connection-time options can all be embedded directly in the connect string. For the environments that still rely on tnsnames.ora, a predictable naming and distribution strategy, tested with tnsping after every change, remains the safer path; see Creating and Maintaining the tnsnames.ora File. Easy Connect Plus does not eliminate sqlnet.ora, though: that file remains the place where logging, tracing, and several client-wide settings not tied to any one connection are configured, which is exactly the topic of this lesson.
• ADR centralizes diagnostic files (alert logs, incident packages, listener traces) under an ADR_BASE directory, even when you still use traditional Net Services parameters.
• Oracle Net parameters such as TRACE_LEVEL_CLIENT, TRACE_LEVEL_SERVER, and listener trace settings are still documented and fully supported in 26ai.
• TLS 1.3, introduced in Oracle Database 23ai and carried forward into 26ai, is the default negotiated protocol version between two 23ai-or-later clients and servers; a client or server on 19c or 21c still negotiates down to TLS 1.2 automatically. If a connectivity problem only appears after a TLS upgrade on one side of a connection, tracing is often the fastest way to confirm whether the two ends actually negotiated the protocol version you expected, rather than silently falling back to an older one.

None of this changes what tracing is for. It changes where you look once you have turned it on: a trace captured in an OCI environment is as likely to need correlating against an OCI Logging entry or a load balancer's own logs as against anything local to the database host, which was rarely a consideration in the Net8 era.

On a client or application tier that still uses sqlnet.ora, you might enable temporary tracing like this:

# sqlnet.ora (Oracle 26ai client) - temporary tracing for diagnostics
TRACE_LEVEL_CLIENT=SUPPORT
TRACE_DIRECTORY_CLIENT=/u01/app/oracle/net_traces
TRACE_FILE_CLIENT=app_client.trc
TRACE_UNIQUE_CLIENT=ON
TRACE_TIMESTAMP_CLIENT=ON

TRACE_LEVEL_CLIENT accepts OFF (0), USER (4), ADMIN (6), or SUPPORT (16); the same scale applies to TRACE_LEVEL_SERVER on the database side. After you reproduce the problem and collect the trace file, disable tracing again, for example by commenting out TRACE_LEVEL_CLIENT or setting it to OFF. A reload is not required for existing or new client connections, since the client reads sqlnet.ora at connect time.

With ADR enabled, which is the default, trace output goes under the client's own ADR home rather than the directory named in TRACE_DIRECTORY_CLIENT. To force the classic text-file layout instead, set DIAG_ADR_ENABLED=OFF and rely on TRACE_DIRECTORY_CLIENT and TRACE_FILE_CLIENT to control the location.

The same mechanism applies on the database server, through the parallel TRACE_LEVEL_SERVER parameter in the server's own sqlnet.ora:

# sqlnet.ora (Oracle 26ai server) - temporary tracing for diagnostics
TRACE_LEVEL_SERVER=ADMIN
TRACE_DIRECTORY_SERVER=/u01/app/oracle/net_traces
TRACE_FILE_SERVER=app_server.trc

Server-side tracing is usually started at ADMIN rather than jumping straight to SUPPORT, since it covers every incoming connection to that database, not just one application's sessions, and a SUPPORT-level trace across all of them can generate a very large volume of output very quickly.

While you are in sqlnet.ora enabling tracing, it is also worth setting sane connection timeouts, so a stuck connection attempt fails fast enough to leave a useful trace entry rather than hanging indefinitely; see Setting TNS Timeout Values for the outbound, inbound, send, and receive timeout parameters.

For the listener, tracing is still controlled in listener.ora or via the Listener Control Utility (lsnrctl). As with any listener parameter, lsnrctl help (or lsnrctl help trace) always reflects the exact syntax your installed release supports, and is worth checking before relying on a remembered example; see the LSNRCTL Help Utility. The general recommendation is to keep TRACE_LEVEL_LISTENER minimal day to day and lean on ADR's own diagnostics first:

# listener.ora - sample snippet
TRACE_LEVEL_LISTENER=SUPPORT
TRACE_DIRECTORY_LISTENER=/u01/app/oracle/net_traces
TRACE_FILE_LISTENER=listener.trc
TRACE_TIMESTAMP_LISTENER=ON
TRACE_UNIQUE_LISTENER=ON

After editing listener.ora directly, run lsnrctl reload to have the listener re-read its configuration without a full restart. You can also toggle tracing dynamically, without editing the file at all:

lsnrctl
LSNRCTL> set current_listener LISTENER
LSNRCTL> set trc_level SUPPORT
LSNRCTL> set trc_directory /u01/app/oracle/net_traces
LSNRCTL> set trc_file listener.trc

In 26ai, this "on-demand" approach to listener tracing fits well with automation and configuration-as-code practices, where you keep changes small, documented, and easily reversible.

Setting a trace level and confirming it took effect are two different steps, and it is worth checking both before you spend time waiting for a trace to capture an intermittent problem. For the listener, lsnrctl status reports the current trace level directly, so a quick status check confirms whether your change was picked up without needing to inspect any files.

For client and server tracing under ADR, adrci is the more reliable way to confirm output is actually being written, rather than guessing at a file path:

adrci> show base -product client
adrci> set base -product client
adrci> show trace app_client.trc

If show trace returns nothing after you have reproduced the problem, the trace level most likely was not applied the way you expected, for example because ADR was quietly writing somewhere other than the classic directory you were watching, rather than because nothing happened on the network. Checking this up front saves you from reproducing a problem two or three times before realizing the trace was never being captured in the first place.

Suppose an application team reports that connections from one particular application server intermittently fail with a timeout, but only during a specific nightly batch window, and only from that one host. The listener's own log looks clean, which narrows the problem toward the client side or the network path between the two hosts rather than the listener itself.

The first move is client tracing, not listener tracing, since the symptom is specific to one client: set TRACE_LEVEL_CLIENT=SUPPORT in that application server's sqlnet.ora, confirm with adrci that trace output is being written, and wait for the batch window. If the resulting trace shows the client successfully resolving the connect string and sending the initial request, but then waiting far longer than expected for a response, the next step is comparing that timestamp against the server-side trace from the same window using TRACE_LEVEL_SERVER=ADMIN, to see whether the delay is happening on the client's side of the network, in transit, or in how long the server took to respond.

This kind of two-sided comparison, client trace against server trace for the same connection window, is usually what finally separates a network-layer problem (a congested link, a firewall doing something unexpected under load) from an application-layer one (the batch job itself competing for database resources at exactly that time). Once the cause is identified, both trace levels go back to OFF, since neither one needs to stay elevated once the specific failure has been caught.

From a configuration-management perspective, turning on Oracle Net logging and tracing should be treated as a controlled change:

• Define when tracing is required (for example, during root-cause analysis of connection timeouts).
• Check the settings into version control along with your sqlnet.ora and listener.ora templates.
• Ensure your runbooks include steps to disable tracing and archive any trace files once investigations are complete.
• In cloud deployments, pair Oracle Net tracing with OCI logging, metrics, and alert rules so that network diagnostics are part of a coherent observability strategy.

A short recap of what turning on logging and tracing actually involves in Oracle 26ai:

• Logging stays on by default through ADR; you rarely need to touch it.
• Tracing stays off by default; you turn it on for a specific component, client, server, or listener, only while actively diagnosing a problem.
• The parameter names and the OFF | USER | ADMIN | SUPPORT scale are unchanged from the Net8 era, even though the files behind them, and where their output lands, have evolved around ADR.
• Confirm a trace is actually being written, with lsnrctl status or adrci, before relying on it to catch an intermittent problem.
• Turn tracing back off once you have what you need.

In summary, you no longer leave high-volume tracing on all the time, but you still need to understand Oracle Net logging and tracing so you can turn them on intelligently when Oracle 26ai network problems arise.