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 23ai, the same concepts live on under the name Oracle Net Services. 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 23ai features such as Easy Connect Plus, TLS 1.3, and the Automatic Diagnostic Repository (ADR).

What logging and tracing actually do

Oracle Net produces two main kinds of diagnostic output:

• Logging – high-level summaries of events (startup, shutdown, connection attempts, errors) written to listener and sqlnet log files.
• 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.:contentReference[oaicite:1]{index=1}

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

Historical view: Net8 and SQL*Net era

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 23ai, 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_*.:contentReference[oaicite:2]{index=2}
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.:contentReference[oaicite:3]{index=3}

Secure Configuration Checklist

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 23c/23ai, but they are now part of a broader diagnostics stack that includes ADR and cloud-centric logging.

Is it still necessary to turn on logging and tracing in Oracle 23ai?

Yes, but only selectively. In Oracle 23ai 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.:contentReference[oaicite:4]{index=4}
• 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.:contentReference[oaicite:5]{index=5}
• 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 23ai is: keep tracing off until you need it, then enable it temporarily with clearly defined scope and retention.

Modern configuration in Oracle 23ai

In Oracle Database 23ai, the mechanics of enabling tracing are essentially the same, 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 many file-based configurations (tnsnames.ora, sqlnet.ora) for common use cases.:contentReference[oaicite:6]{index=6}
• ADR centralizes diagnostic files (alert logs, incident packages, listener traces) under an ADR_BASE directory, even when you still use traditional Net Services parameters.:contentReference[oaicite:7]{index=7}
• Oracle Net parameters such as TRACE_LEVEL_CLIENT, TRACE_LEVEL_SERVER, and listener trace settings are still documented and supported in 23c/23ai.:contentReference[oaicite:8]{index=8}

Example: enabling client tracing in 23ai

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

# sqlnet.ora (Oracle 23ai 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
  

After you reproduce the problem and collect the trace file, you disable tracing again (for example, by commenting out TRACE_LEVEL_CLIENT or setting it to OFF).

Example: enabling listener tracing in 23ai

For the listener, tracing is still controlled in listener.ora or via the Listener Control Utility (lsnrctl):

# 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
  

You can also toggle tracing dynamically with:

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 23ai, 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.:contentReference[oaicite:9]{index=9}

Where this fits in a modern configuration-management workflow

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.

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 23ai network problems arise.