Configuring Oracle Log and Trace Files

Oracle Net Services log and trace output is controlled by parameters in each component's own configuration file, plus, for the database itself, a dedicated diagnostic parameter. For an Oracle server, listener logging and tracing are governed by listener.ora. For Oracle Net clients, logging and tracing are controlled by sqlnet.ora, remembering that a sqlnet.ora file exists on both the client and the server. Oracle Connection Manager has its own file, cman.ora. This lesson walks through configuring each one.

The previous two lessons covered what logging and tracing record and where their output ends up by default. This lesson is about changing those defaults deliberately: turning tracing on for a specific component, pointing output somewhere other than its default location, or confirming exactly what a given component is currently configured to do. The same four configuration points, the database, the listener, the client and server, and Oracle Connection Manager, come up again and again, so it is worth learning the pattern once rather than treating each one as a separate problem.

A note on terminology before diving in: older documentation for this topic, and some of what you will still find indexed online, refers to "SQL*Net" and "Net8" clients and to an "Oracle Names" naming method. All three are legacy terms. Current Oracle Net deployments typically use Easy Connect Plus or an OCI-native connection method rather than classic naming styles, and Directory Naming has long since replaced Oracle Names (also known as Oracle Names Server, or ONAMES) as the directory-based naming method; see Oracle 23ai OCI Service Connection Methods for the current approach. The mechanics of configuring logging and tracing covered in this lesson, however, have changed very little across that terminology shift.

Since Oracle 11g, database diagnostics are collected into the Automatic Diagnostic Repository (ADR), which remains on by default in Oracle 26ai. The DIAGNOSTIC_DEST initialization parameter controls where ADR is rooted; it defaults to $ORACLE_BASE and can be changed while the instance is running:

ALTER SYSTEM SET DIAGNOSTIC_DEST='/path' SCOPE=BOTH;

The ADR home for a database instance follows the pattern $DIAGNOSTIC_DEST/diag/rdbms/<db>/<instance>/. Within it, the alert log is kept as alert/log.xml, with a plain-text mirror at trace/alert_<instance>.log, and individual process trace files live under trace/. The adrci utility is the standard way to browse all of this, using commands such as show homes, show alert, and show trace, without navigating the directory structure by hand.

For a single session rather than the whole instance, a targeted trace is usually more useful than raising the instance-wide level:

ALTER SESSION SET EVENTS '10046 trace name context forever, level 12';

DBMS_MONITOR provides a more structured, non-event-based way to do the same thing for a specific session, client identifier, or service, and is generally the preferred approach when you need the trace to follow a particular user or module rather than a single connected session.

When more than one ADR home exists on a server, for example a database instance alongside a listener and an Oracle Connection Manager instance, adrci needs to know which one you mean before it can show you anything. The SHOW BASE command reports the current ADR_BASE for a given product (SHOW BASE -product client, for instance), and SET BASE points the session at the right one. Once you are looking at the right home, adrci can also package everything related to a specific problem, incident metadata and the diagnostic files that go with it, into a single zip file for Oracle Support, rather than you hunting down each trace file by hand.

Listener logging and tracing are set per listener name in listener.ora:

LOGGING_LISTENER = ON
TRACE_LEVEL_LISTENER = OFF

TRACE_LEVEL_LISTENER accepts OFF, USER, ADMIN, or SUPPORT, or a numeric value from 0 to 16. With ADR enabled, which is the default, the classic LOG_DIRECTORY_LISTENER and TRACE_DIRECTORY_LISTENER parameters are ignored, and output instead goes under the listener's own ADR home, diag/tnslsnr/<host>/<listener_name>/.

The fastest way to see a listener's current logging and tracing configuration, including where its log file actually lives, is the STATUS command. Click the View Code button to see an example:

dbhost01 $ lsnrctl status

LSNRCTL for Linux: Version 26.1.0.0.0 - Production on 02-OCT-2026 09:14:08

Copyright (c) 1991, 2026, Oracle.  All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=IPC)(KEY=fred))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 26.1.0.0.0 - Production
Start Date                28-SEP-2026 06:02:15
Uptime                    4 days 3 hr. 11 min. 53 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/app/oracle/product/26.1.0/dbhome_1/network/admin/listener.ora
Listener Log File         /u01/app/oracle/diag/tnslsnr/dbhost01/listener/alert/log.xml
Services Summary...
  extproc       has 1 service handler(s)
  fred          has 1 service handler(s)
  tom           has 1 service handler(s)
The command completed successfully

Notice that the listener log file lives under the ADR path, alert/log.xml, rather than the classic network/log/listener.log location; that is the ADR-enabled default. This is the fastest way to see the location of the log file if you need to reference it while diagnosing a connection problem. The only other way to find it is to read the relevant parameters directly out of listener.ora.

All errors encountered in Oracle Net Services are appended to the listener or client/server log. As covered in the previous lesson, this log file provides additional information for an administrator when the error message shown on screen is not enough on its own to understand the failure.

Changes made this way, by setting a parameter directly in listener.ora, take effect the next time the listener starts. To change the running listener's trace level without a restart and have the change persist, set it from the Listener Control utility and then save it:

LSNRCTL> SET TRACE_LEVEL ADMIN
LSNRCTL> SAVE_CONFIG

SAVE_CONFIG writes the listener's current trace level, trace file, trace directory, and logging settings back into listener.ora, so the change survives the next restart instead of reverting to whatever was last saved to the file. If a host runs more than one listener, remember to include the listener name on commands like this one; parameters and commands issued without a name apply to a listener called LISTENER by default.

On the client and server side, tracing is controlled by TRACE_LEVEL_CLIENT and TRACE_LEVEL_SERVER, each accepting OFF, USER, ADMIN, or SUPPORT, alongside DIAG_ADR_ENABLED, which defaults to ON:

TRACE_LEVEL_CLIENT = USER
DIAG_ADR_ENABLED = ON

If ADR is turned off for a given client or server, the classic parameters take over: LOG_DIRECTORY_CLIENT, TRACE_DIRECTORY_CLIENT, TRACE_FILE_CLIENT, and their _SERVER equivalents, each pointing at a specific directory and file name. A complete non-ADR client configuration might look like this:

DIAG_ADR_ENABLED_CLIENT = OFF
LOG_DIRECTORY_CLIENT = /oracle/network/log
TRACE_DIRECTORY_CLIENT = /oracle/network/trace
TRACE_FILE_CLIENT = cli
TRACE_LEVEL_CLIENT = USER

The server side mirrors this exactly, with _SERVER in place of _CLIENT on each parameter. There is no need to set these at all if you are content with ADR's own directory structure; they exist specifically for environments that still expect the classic flat-file layout.

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

Oracle Connection Manager is configured through the PARAMETER_LIST section of cman.ora, or at runtime through its own control utility, CMCTL:

PARAMETER_LIST =
  (LOG_LEVEL = SUPPORT)
  (TRACE_LEVEL = SUPPORT)
  (EVENT_GROUP = INIT_AND_TERM,MEMORY_OPS,PROCESS_MGMT)

Both LOG_LEVEL and TRACE_LEVEL accept the same OFF | USER | ADMIN | SUPPORT values used elsewhere, and EVENT_GROUP controls which categories of event get logged; it defaults to NONE, and accepts a comma-separated list of event categories such as INIT_AND_TERM (startup and shutdown events) and PROCESS_MGMT (gateway process lifecycle events) rather than an all-or-nothing switch. At runtime, the same settings can be changed without editing the file:

cmctl SET LOG_LEVEL SUPPORT -c <instance>
cmctl SET TRACE_LEVEL SUPPORT -c <instance>

As with the listener and the client/server files, LOG_DIRECTORY and TRACE_DIRECTORY in cman.ora are ignored once ADR is enabled, which it is by default. Oracle Connection Manager's trace files follow the naming pattern covered in the previous lesson: <instance>_pid.trc for the Connection Manager listener itself, <instance>_cmgw_pid.trc for each CMGW gateway process, and <instance>_cmadmin_pid.trc for the CMADMIN process.

Turn tracing back off once you have what you need. A SUPPORT-level trace on any component is large and meant to be short-lived, not a standing configuration.

Suppose a connection that routes through Oracle Connection Manager is failing intermittently, and the listener's own log shows nothing unusual, meaning the request is likely failing somewhere between the client and CMAN rather than between CMAN and the listener. The configuration change needed to investigate touches two files, not one.

On the client, raise TRACE_LEVEL_CLIENT to USER in sqlnet.ora and reproduce the failure. If the client-side trace shows the request reaching Oracle Connection Manager but getting no further, the next step is CMAN's own trace, not the listener's:

cmctl SET TRACE_LEVEL SUPPORT -c cman1

Reproducing the failure again now generates a detailed trace under CMAN's own instance, in the files named earlier in this lesson. Once the cause is confirmed, both trace levels go back down, the client's to OFF and CMAN's to OFF as well, since neither one needs to stay elevated once the specific failure has been caught.

This two-sided approach, raising the trace level on whichever components sit on either side of the suspected failure point rather than everything at once, keeps the volume of trace output manageable and keeps the resulting files focused on the part of the path that actually needs investigating.

Component	Default Log File
Client and server	sqlnet.log
Listener	listener.log (classic) or alert/log.xml under ADR
Oracle Connection Manager	A per-process log file, following the same PID-based naming pattern as its trace files

Older course material also listed a names.log file for an Oracle Names server. Oracle Names has had no current replacement of its own for many releases now; Directory Naming (see the link above) is the modern directory-based naming method, and no current log file table includes an Oracle Names entry.

Note: If a standard log directory is not set for a client, Oracle places sqlnet.log in whatever directory the client application happened to be run from. On a workstation running several different client tools, each tool's working directory, that means a separate, easily-missed sqlnet.log can end up scattered in several places rather than one file in a predictable location: a reporting tool run from one directory, a data-loading script run from another, and a developer's own client code run from a third, each quietly keeping its own copy rather than contributing to a single history you can review later. Setting LOG_DIRECTORY_CLIENT in sqlnet.ora avoids this by giving every client connection from that machine a single, known log location, regardless of which directory the connecting process happens to be started from.

Configuring logging and tracing comes down to the same small set of moves repeated across four places: the database's DIAGNOSTIC_DEST and ADR, listener.ora, sqlnet.ora on both the client and server, and cman.ora if Oracle Connection Manager is in the path.

• Logging parameters are generally left at their defaults; ADR keeps them on without further configuration.
• Tracing parameters follow the same OFF | USER | ADMIN | SUPPORT scale in every file that has them, with Oracle Connection Manager's admin level being the one exception, at 10 rather than 6.
• Runtime utilities, lsnrctl and cmctl, let you change these settings without a restart, and a command like SAVE_CONFIG makes a runtime change to the listener persistent.
• Classic, non-ADR parameters still work and are documented here, but are only needed when ADR is deliberately disabled.

The next lesson covers the Oracle Net tracing parameters in more detail.