Oracle Network Products Troubleshooting Guide

Library

Product

Contents

Index

Tracing

How to Set Trace Parameters
How to Invoke Tracing
Trace Files
Summary of Trace Parameters
Valid SQLNET.ORA Diagnostic Parameters
Valid LISTENER.ORA Diagnostic Parameters
Valid INTCHG.ORA Diagnostic Parameters
Valid NAMES.ORA Diagnostic Parameters
Examples of Tracing
Example of a Trace File

This chapter describes tracing, which can be used to examine application connections across the network. It explains how to invoke tracing and how to use trace files to diagnose and resolve problems. The chapter describes:

how to set tracing parameters

how to invoke tracing

examples of tracing

sample trace output

Note: Information in this section is generic to all operating system environments. You may require further information from the Oracle operating system-specific documentation for your platform.

How to Set Trace Parameters

There are several ways to set non-default tracing parameters. (For information about defaults see Tables 3-2 tthrough 3-7, and Appendix A.)

Set non-default tracing parameters in the network definition using Oracle Network Manager.

Client tracing and server tracing are governed by parameters in the SQLNET.ORA file, set in the Client Profile property sheet.

Listener tracing is controlled by parameters in the LISTENER.ORA file, set in the Listener property sheet.

MultiProtocol Interchange component tracing is controlled by parameters in the INTCHG.ORA file, set in the Interchange property sheet.

Oracle Names tracing is controlled by parameters in the NAMES.ORA file, set in the Names Server property sheet.

Note: If you have a self-configuring network using Oracle Names and the dynamic discovery option, you must add the trace parameters manually to the NAMES.ORA and LISTENER.ORA files.

Oracle Network Manager Administrator's Guide

Set parameters governing server tracing in the SQLNET.ORA file using a text editor.

For individual clients, use the SQLNET.ORA Editor, part of the Client Status Monitor. You can turn client tracing on or off and set the level of tracing using this utility. You can also set a non-default name for the trace output file and the directory in which it is stored. See the next chapter for further details.

For other network components, use the appropriate control utility to turn tracing on and off. For example, using Oracle Network Manager you can set the listener trace level, and non-default name and location for the trace file in the LISTENER.ORA file. To turn tracing on and off, use the TRACE command of the Listener Control Utility. For the correct syntax see Understanding SQL*Net .

How to Invoke Tracing

The steps used to invoke tracing are outlined here. Each step is fully described in subsequent sections.

1. Choose the component to be traced:

client

server

listener

Connection Manager and pump (cmanager)

Navigator (navigator)

Names Server

Names Control Utility

TNSPING Utility

2. If an existing trace file from a previous trace session exists for a listener or a client and you need to retain the information in it, save that file under another name. Otherwise, the new trace file will overwrite the existing trace file. (For Interchange components and the server, the trace facility appends a process identifier to each trace file, so each one is unique.)

For the Names Server, the trace facility appends a process identifier to each trace file only if NAMES.TRACE_UNIQUE is set to ON or TRUE in the NAMES.ORA file. For the Names Control Utility, the trace facility appends a process identifier to each trace file only if NAMESCTL.TRACE_UNIQUE is set to ON or TRUE in the SQLNET.ORA file. To ensure unique trace files, you must set NAMES.TRACE_UNIQUE to ON in NAMES.ORA, then restart the Names Server. You cannot set this from the Names Control Utility.

3. The trace facility for the listener is controlled through the Listener Control Utility. The trace facilities for the Connection Manager and pumps and for the Navigator are invoked through the Interchange Control Utility. For the listener, the LSNRCTL TRACE command can be used to set the trace level while the component is running; for Interchange components, the INTCTL TRACE_ON command does the same thing.

Understanding SQL*Net

Oracle MultiProtocol Interchange Administrator's Guide

Oracle Names Administrator's Guide

that corresponds to the component traced. The component configuration files are SQLNET.ORA

, LISTENER.ORA

, INTCHG.ORA

, and NAMES.ORA

. The trace parameters are described in the section "

Summary of Trace Parameters

summary of all trace parameters

5. Execute or start the component to be traced. If the trace component configuration files are modified while the component is running, the modified trace parameters will take effect the next time the component is invoked or restarted. Instructions for each component follow:

client Set the trace parameters in the client-side SQLNET.ORA and invoke a client application, such as SQL*Plus, a Pro*C application, or any application that uses the Oracle network products. You can set or edit the trace parameters using the Client Profile property sheet in Oracle Network Manager.

server Set the trace parameters in the server-side SQLNET.ORA. The next process started by the listener will have tracing enabled. The trace parameters must be created or edited manually.

listener Use the Listener property sheet in Network Manager to set the trace parameters in LISTENER.ORA and start the listener from the Listener Control Utility or command line. See Understanding SQL*Net for specific syntax.

Connection Manager Use the Network Manager to set the trace parameters in INTCHG.ORA and start the Connection Manager from the Interchange Control Utility or command line. The pumps are started automatically with the Connection Manager, and their trace files are controlled by the trace parameters for the Connection Manager. For specific syntax guidelines, see the Oracle MultiProtocol Interchange Administrator's Guide.

Navigator Use the Network Manager to set the trace parameters in INTCHG.ORA and start the Navigator from the Interchange Control Utility or command line. . For specific syntax guidelines, see the Oracle MultiProtocol Interchange Administrator's Guide.

Names Server Use the Network Manager to set the trace parameters in NAMES.ORA and start the Names server from the Names Control Utility or command line. For specific syntax guidelines, see the Oracle Names Administrator's Guide.

Names Control Utility Set the trace parameters in SQLNET.ORA and start the Names Control Utility from the command line. For specific syntax guidelines, see the Oracle Names Administrator's Guide.

6. Be sure to turn tracing off when you do not need it for a specific diagnostic purpose.

Trace Files

This section describes the configuration files that contain trace parameters and the trace output files.

The trace parameters are defined in the same configuration files as are the log parameters. Table 3 - 1 shows the configuration files for different network components and the default names of the trace files they generate.

Table 3 - 1. Trace Parameters and Component Configuration Files

Trace Parameters Corresponding to Configuration Files Output Files
Client SQLNET.ORA SQLNET.TRC
Server SQLNET.TRC
TNSPING Utility TNSPING.TRC
Names Control Utility NAMESCTL.TRC
Listener LISTENER.ORA LISTENER.TRC
Interchange INTCHG.ORA
Connection Manager CMG.TRC
Pumps PMP.TRC
Navigator NAV.TRC
Names Server NAMES.ORA NAMES.TRC

The configuration file for each component is located on the computer running that component.

The trace characteristics for two or more components of an Interchange are controlled by different parameters in the same configuration file. For example, there are separate sets of parameters for the Connection Manager and the Navigator that determine which components will be traced, and at what level.

Similarly, if there are multiple listeners on a single computer, each listener is controlled by parameters that include the unique listener name in the LISTENER.ORA file.

For each component, the configuration files contain the following information:

a valid trace level to be used (Default is OFF)

the trace filename (optional)

the trace file directory (optional)

A summary of all trace parameters is provided in Table 3 - 2 through Table 3 - 7.

See the Oracle operating system-specific documentation for your platform to determine where these files are expected to reside and where you can find sample files.

Summary of Trace Parameters

Three common trace parameters control the level of detail of the trace, the name of the trace file, and the location of the trace file. There are defaults for all three of these parameters. If you choose the defaults, you do not need to provide any values for the trace parameters. To change the defaults, use Oracle Network Manager.

Trace Levels

You can set trace levels to provide different amounts of trace information. For each component, there are three levels:

OFF

This setting signifies that no trace output should be generated. This setting is the default.

USER

This setting is intended for database administrators or users who are administering TNS products, but do not have extensive network knowledge. The USER trace level generates only English sentences describing high-level significant networking events.

ADMIN

This setting is intended for network or database administrators with more knowledge of network terms and concepts. The ADMIN trace level generates all of the USER level statements plus additional information such as TNS addresses and detailed events.

The parameters are of the form:

TRACE_LEVEL_component = [OFF|USER|ADMIN]

For example, the following parameter, set in Oracle Network Manager, would produce trace output for the client at the administrator level:

TRACE_LEVEL_CLIENT = ADMIN

Trace Filenames

You can control the name of the trace file for each component. Any valid string can be used as a trace filename. The parameters are of the form:

TRACE_FILE_component = string

For example, the following parameter would send listener trace output to a file called TEST.TRC on the server machine:

TRACE_FILE_LISTENER = TEST

Change the default trace filename using Oracle Network Manager.

Note: On most operating systems, the suffix .TRC is automatically appended to the filename you provide for the parameter; do not include the suffix when you enter the file name in Oracle Network Manager.

Note: You cannot change the default name, PMP.TRC, of the trace file for the pump.

Note: Some platforms have restrictions on the properties of a filename. See your Oracle operating system-specific manuals for platform specific restrictions.

Trace File Directories

You can control the destination directory of the trace file for each component, except the Connection Manager and Navigator, through Oracle Network Manager.

Examples are specific to different operating systems. An example on a UNIX system might be:

TRACE_DIRECTORY_LISTENER = /tmp/trace

Note: Some platforms have restrictions on the properties of a directory name. See your Oracle operating system-specific manuals for platform specific restrictions.

Unique Trace Files for Clients

Normally, when a new trace file is created for a client, it overwrites any existing trace file for that component. If you want to save an existing trace file, you must change its name before running the trace facility again. However, if the TRACE_UNIQUE_CLIENT parameter is set to ON, the trace facility appends a process identifier to the name of each trace file generated so that several can coexist. The format of the appended process identifier is platform specific. The default is OFF.

Note: Trace files are usually very large. If this parameter is set to ON, the number of large trace files created could interfere with the available disk space on your machine. Therefore, turn this parameter on only for specific reasons and delete the resulting files when they are no longer useful.

Unique Trace Files for Servers and Interchange Components

When tracing is turned on for servers or Interchange components, the trace files generated automatically have process identifiers attached, so that new trace files do not overwrite existing ones. There is no parameter needed to control this feature. Be careful not to let too many trace files accumulate, however, as they are usually quite large.

Note: This feature is not implemented on all operating systems. See the Oracle operating system-specific documentation for your platform for further information.

Unique Trace Files for Names Servers

When tracing is turned on to trace a Names Server, by default the trace files generated have process identifiers attached, so that new trace files do not overwrite existing ones. Be careful not to let too many trace files accumulate, however, as they are usually quite large. You can turn this feature off using Oracle Network Manager.

Note: This feature is not implemented on all operating systems. See the Oracle operating system-specific documentation for your platform for further information.

Unique Trace Files for Names Control Utility

When tracing is turned on to trace the Names Control Utility itself, the trace files generated have process identifiers attached, so that new trace files do not overwrite existing ones. This feature is controlled by the NAMESCTL.TRACE_UNIQUE parameter. Be careful not to let too many trace files accumulate, however, as they are usually quite large.

Note: This feature is not implemented on all operating systems. See the Oracle operating system-specific documentation for your platform for further information.

Tracing the TNSPING Utility

You can manually add the following two tracing parameters to SQLNET.ORA to perform tracing on the TNSPING utility:

TNSPING.TRACE_LEVEL 
TNSPING.TRACE_DIRECTORY

Valid SQLNET.ORA Diagnostic Parameters

The SQLNET.ORA file may contain optional parameters to control logging and tracing of clients and servers, and optional parameters for tracing the NAMESCTL utility and the TNSPING utility.

Parameters for Clients and Servers

The following table shows the valid SQLNET.ORA parameters used in logging and tracing of SQL*Net version 2 clients and servers. A more detailed description of each parameter is available in Appendix A, "Trace and Log Parameter Reference".

Table 3 - 2. SQLNET.ORA Diagnostic Parameters

Parameters Default Values Example (DOS client, UNIX server)
TRACE_LEVEL_CLIENT OFF [OFF | USER |ADMIN] TRACE_LEVEL_CLIENT=USER
TRACE_FILE_CLIENT SQLNET.TRC string TRACE_FILE_CLIENT=CLIENT
TRACE_DIRECTORY_CLIENT O/S specific valid directory TRACE_DIRECTORY_CLIENT= c:\NET\ADMIN
TRACE_UNIQUE_CLIENT OFF [ON|OFF] TRACE_UNIQUE_CLIENT=ON
LOG_FILE_CLIENT SQLNET.LOG string LOG_FILE_CLIENT=CLIENT
LOG_DIRECTORY_CLIENT O/S specific valid directory LOG_DIRECTORY_CLIENT=c:\NET\ADMIN
TRACE_LEVEL_SERVER OFF [OFF | USER | ADMIN] TRACE_LEVEL_SERVER=ADMIN
TRACE_FILE_SERVER SQLNET.TRC string TRACE_FILE_SERVER=unixsrv_2345.trc
TRACE_DIRECTORY_SERVER O/S specific valid directory TRACE_DIRECTORY_SERVER=/tmp/trace
LOG_FILE_SERVER SQLNET.LOG string LOG_FILE_SERVER=unixsrv.log
LOG_DIRECTORY_SERVER O/S specific valid directory LOG_DIRECTORY_SERVER=/tmp/trace

Note: You control both log and trace parameters for the client through Oracle Network Manager. You can also control trace parameters for the client through the SQLNET.ORA Editor. You control log and trace parameters for the server by manually adding the desired parameters to the SQLNET.ORA file.

For more information about the SQLNET.ORA Editor, see Chapter 4.

Parameters for Names Control Utility

The following table shows the valid SQLNET.ORA parameters used in tracing the Names Control Utility. A more detailed description of each parameter is available in Appendix A, ``Trace and Log Parameter Reference".

Note: You must add these parameters manually to the SQLNET.ORA file. You cannot create them using Oracle Network Manager.

Table 3 - 3. NAMESCTL Utility Diagnostic Parameters

Parameters Default Values Example (UNIX server)
NAMESCTL.TRACE_LEVEL OFF [OFF | USER | ADMIN] NAMESCTL.TRACE_LEVEL=user
NAMESCTL.TRACE_FILE namesctl.trc file NAMESCTL.TRACE_FILE=nc_south.trc
NAMESCTL.TRACE_DIRECTORY O/S specific directory NAMESCTL.TRACE_DIRECTORY= /oracle7/network/trace
NAMESCTL.TRACE_UNIQUE FALSE TRUE/FALSE or ON/OFF NAMESCTL.TRACE_UNIQUE=TRUE

Parameters for TNSPING

If you want to trace the TNSPING utility, you can add these parameters to SQLNET.ORA.

Note: You can add these parameters to the SQLNET.ORA file using the SQLNET.ORA Editor. You cannot create them using Oracle Network Manager.

For more information about the SQLNET.ORA Editor, see Chapter 4.

Table 3 - 4. TNSPING Diagnostic Parameters

Parameters Default Values Example (UNIX server)
TNSPING.TRACE_LEVEL OFF [OFF | USER | ADMIN] TNSPING.TRACE_LEVEL=user
TNSPING.TRACE_DIRECTORY O/S specific directory TNSPING.TRACE_DIRECTORY= /oracle7/network/trace

Valid LISTENER.ORA Diagnostic Parameters

The following table shows the valid LISTENER.ORA parameters used in logging and tracing of the listener. A more detailed description of each parameter is available in Appendix A, "Trace and Log Parameter Reference".

Table 3 - 5. LISTENER.ORA Diagnostic Parameters

Parameters Default Values Example (VMS)
TRACE_LEVEL_LISTENER OFF [OFF | USER | ADMIN] TRACE_LEVEL_LISTENER=OFF
TRACE_FILE_LISTENER LISTENER.TRC string TRACE_FILE_LISTENER=LISTENER
TRACE_DIRECTORY_LISTENER O/S specific valid directory TRACE_DIRECTORY_LISTENER= $ORA_SQLNETV2
LOG_FILE_LISTENER LISTENER.LOG string LOG_FILE_LISTENER=LISTENER
LOG_DIRECTORY_LISTENER O/S specific valid directory LOG_DIRECTORY_LISTENER=$ORA_ ERRORS

Valid INTCHG.ORA Diagnostic Parameters

The following table shows the valid INTCHG.ORA parameters used in logging and tracing of the Interchange. A more detailed description of each parameter is available in Appendix A, ``Trace and Log Parameter Reference".

Table 3 - 6. INTCHG.ORA Diagnostic Parameters

Parameters Default Values Example (OS/2 Interchange)
TRACE_LEVEL_CMANAGER OFF [OFF|USER|ADMIN] TRACE_LEVEL_CMANAGER=USER
TRACE_FILE_CMANAGER CMG.TRC string TRACE_FILE_CMANAGER= CMANAGER
TRACE_DIRECTORY_CMANAGER O/S specific valid directory TRACE_DIRECTORY_CMANAGER= C:\ADMIN
LOG_FILE_CMANAGER INTCHG.LOG string LOG_FILE_CMANAGER=CMANAGER
LOG_DIRECTORY_CMANAGER O/S specific valid directory LOG_DIRECTORY_CMANAGER= C:\ADMIN
LOGGING_CMANAGER OFF OFF|ON LOGGING_CMANAGER=OFF
LOG_INTERVAL_CMANAGER 60 minutes Any number of minutes LOG_INTERVAL_CMANAGER=60
TRACE_LEVEL_NAVIGATOR OFF [OFF|USER|ADMIN] TRACE_LEVEL_NAVIGATOR=ADMIN
TRACE_FILE_NAVIGATOR NAV.TRC string TRACE_FILE_NAVIGATOR= NAVIGATOR
TRACE_DIRECTORY_NAVIGATOR O/S specific valid directory TRACE_DIRECTORY_NAVIGATOR= C:\ADMIN
LOG_FILE_NAVIGATOR NAVGATR.LOG string LOG_FILE_NAVIGATOR=NAVIGATOR
LOG_DIRECTORY_NAVIGATOR O/S specific valid directory LOG_DIRECTORY_NAVIGATOR= C:\ADMIN
LOGGING_NAVIGATOR OFF OFF|ON LOGGING_NAVIGATOR=OFF
LOG_LEVEL_NAVIGATOR ERRORS ERRORS|ALL LOG_LEVEL_NAVIGATOR=ERRORS

Valid NAMES.ORA Diagnostic Parameters

The following table shows the valid NAMES.ORA parameters used in logging and tracing of the Names Server. A more detailed description of each parameter is available in Appendix A, ``Trace and Log Parameter Reference".

Table 3 - 7. NAMES.ORA Diagnostic Parameters

Parameters Default Values Example (UNIX server)
NAMES.TRACE_LEVEL OFF [OFF | USER | ADMIN] NAMES.TRACE_LEVEL=ADMIN
NAMES.TRACE_FILE names.trc file NAMES.TRACE_FILE=nsrv3.trc
NAMES.TRACE_DIRECTORY O/S specific directory NAMES.TRACE_DIRECTORY=/oracle7/network/trace
NAMES.TRACE_UNIQUE FALSE TRUE/FALSE or ON/OFF NAMES.TRACE_UNIQUE=TRUE
NAMES.LOG_FILE names.log file NAMES.LOG_FILE=nsrv1.log
NAMES.LOG_DIRECTORY O/S specific directory NAMES.LOG_DIRECTORY= /oracle7/network/log

Examples of Tracing

This section contains several examples of tracing possibilities. For each example the entries in the configuration files are shown with the relative locations of the trace configuration and files. The following trace options are demonstrated:

tracing a client

tracing a listener

tracing a server

tracing both the server and listener

tracing the Connection Manager and pump

tracing the Navigator

tracing the Connection Manager, pump, and Navigator

Example 1: Tracing a Client

Figure 3 - 1 shows a trace invoked by a client on a Microsoft Windows machine. The client trace parameters are determined by the SQLNET.ORA file, and the trace output is generated to the CLIENT.TRC file on the client machine.

Figure 3 - 1. Tracing the Client

In Oracle Network Manager, on the Tracing page of the Client Profile property sheet, Trace Level is set to USER, Trace File to CLIENT, and Trace Directory to C:\trace. The SQLNET.ORA would therefore contain the following entries:

TRACE_LEVEL_CLIENT = USER
TRACE_FILE_CLIENT = CLIENT
TRACE_DIRECTORY_CLIENT = C:\TRACE

The first line sets the trace level, the second determines the name of the trace file, and the third indicates the location of the trace file.

Example 2: Tracing a Listener

Figure 3 - 2 shows an example of a listener trace on a computer running the UNIX operating system.

Figure 3 - 2. Tracing the Listener

To activate this tracing, on the Tracing page of the Listener property sheet in Oracle Network Manager, set Trace Level to ADMIN and Trace File to TESTTRC. The listener parameter file LISTENER.ORA that invokes trace for the listener would then include the following lines:

TRACE_LEVEL_LISTENER = ADMIN
TRACE_FILE_LISTENER = TESTTRC

In this example, the trace would occur at the ADMIN level and the resulting trace information would be written to the TESTTRC.TRC file in the default trace file location for that platform. For example:

$ORACLE_HOME/network/trace/TESTTRC.trc

Example 3: Tracing a Server

shows an example of a server trace on a VMS machine.

Figure 3 - 3. Tracing the Server

To set tracing for the server, you must manually edit the SQLNET.ORA file. In this example, the server's SQLNET.ORA file would include the following lines:

TRACE_LEVEL_SERVER = ADMIN
TRACE_FILE_SERVER = SERVER

The resulting trace file would be:

ORA_RDBMS:[NETWORK.TRACE]SERVER_44A17BEA.TRC

Note that the server's process identifier, in hexadecimal notation, is included in the trace filename.

Example 4: Tracing Both the Server and the Listener

Figure 3 - 4 shows the configuration parameters used to produce trace files for both the server and listener on a VMS machine.

Figure 3 - 4. Tracing the Server and Listener

Since the server and the listener use separate configuration files, you must use two different files to invoke tracing for both the server and the listener. Parameters in the server's SQLNET.ORA file, which you must set using a text editor, would be:

# SERVER Trace Parameters
TRACE_LEVEL_SERVER = ADMIN
TRACE_FILE_SERVER = SERVER

Trace parameters in the server's LISTENER.ORA file ( set using Oracle Network Manager) would be:

# TNS Listener Trace Parameters
TRACE_LEVEL_LISTENER = ADMIN
TRACE_FILE_LISTENER = TNSLSNR

The resulting trace filenames and directories would be:

ORA_RDBMS:[NETWORK.TRACE]SERVER_44A17BEA.TRC
ORA_RDBMS:[NETWORK.TRACE]TNSLSNR.TRC

Example 5: Tracing the Connection Manager and Pump

Figure 3 - 5 shows the configuration file used when tracing the Connection Manager and pump components of the MultiProtocol Interchange on a machine running OS/2.

Figure 3 - 5. Tracing the Connection Manager and Pump

On the Connection Tracing page of the Interchange property sheet in Oracle Network Manager, Trace Level is set to ADMIN and Trace File is designated as CMNGR. The INTCHG.ORA configuration file therefore includes the following lines:

TRACE_LEVEL_CMANAGER = ADMIN
TRACE_FILE_CMANAGER = CMNGR

These parameters specify tracing for the Connection Manager and pump components of the Interchange at the administrator level, and a non-default name for the Connection Manager trace file.

Note: The pump component shares the trace parameters of the Connection Manager, but it generates a separate trace file with the unchangeable default name PMPpid.TRC.

Based on these parameters, the trace files generated would be:

C:\ORAOS2\NETWORK\TRACE\PMP2A.TRC
C:\ORAOS2\NETWORK\TRACE\CMNGR7B.TRC

Note that the trace filenames include process identifiers in hexadecimal notation.

Example 6: Tracing the Navigator

Figure 3 - 6 shows the configuration file used and the resulting trace file generated for a Navigator on a system running UNIX.

Figure 3 - 6. Tracing the Navigator

On the Navigation Tracing page of the Interchange property sheet in Oracle Network Manager, Trace Level is set to ADMIN, Trace File is set to NAVIGTR, and Trace Directory to /tmp/trace. The INTCHG.ORA component configuration file therefore contains the following lines:

# Navigator Trace Parameters
TRACE_LEVEL_NAVIGATOR = ADMIN
TRACE_FILE_NAVIGATOR = NAVIGTR
TRACE_DIRECTORY_NAVIGATOR=/tmp/trace

These parameters indicate that the Navigator is to be traced at the administrator level with a trace file named NAVIGTR_pid.TRC to be located in /tmp/trace; for example:

 /tmp/trace/NAVIGTR_9453.TRC

Example 7: Tracing the Connection Manager, Pump, and Navigator

Figure 3 - 7 shows the configuration file used when tracing the Connection Manager, pump, and Navigator, and the trace files that are generated.

Figure 3 - 7. Tracing All Components of an Interchange

The trace parameters are set in the tracing pages of the Interchange property sheet in Oracle Network Manager. On the Connection Tracing page, Trace Level is set to ADMIN. On the Navigation Tracing page, Trace Level is set to ADMIN and Trace File is set to NAVIGTR.

The INTCHG.ORA configuration file therefore includes the following lines:

# Interchange Connection Manager Parameters
# Use default name of CMG.TRC for trace file
# Pump trace is controlled by Connection Manager parameters
TRACE_LEVEL_CMANAGER = ADMIN
#
# Navigator Trace Parameters
TRACE_LEVEL_NAVIGATOR = ADMIN
TRACE_FILE_NAVIGATOR = NAVIGTR

These parameters specify the Connection Manager, pump, and Navigator to be traced at the administrator level. The Connection Manager trace file will use the default filename, but the Navigator trace file will be created with a specified name. Note that no TRACE_LEVEL parameter is specified for the pump, because the pump shares the TRACE_LEVEL parameter with the Connection Manager; the pump's trace filename cannot be changed.

Example of a Trace File

In the following example, the SQLNET.ORA file includes the following line:

TRACE_LEVEL_CLIENT = ADMIN

The following trace file is the result of a connection attempt that failed because the hostname is invalid.

The trace output is a combination of debugging aids for Oracle specialists and English information for network administrators. Several key events can be seen by analyzing this output from beginning to end:

The client describes the outgoing data in the connect descriptor used to contact the server.

An event is received (connection request).

A connection is established over the available transport (in this case TCP/IP).

The connection is refused by the application, which is the listener.

The trace file shows the problem, as follows:
-<FATAL?>- *** hostname lookup failure! ***

Error 12545 is reported back to the client.

If you look up Error 12545

of this guide, you will find the following description:

ORA-12545 TNS:Name lookup failure

Cause: A protocol specific ADDRESS parameter cannot be resolved.

Action: Ensure the ADDRESS parameters have been entered correctly; the most likely incorrect value is the node name.

Sample Trace File

The following trace file has been annotated to make it easier to understand:

--- TRACE CONFIGURATION INFORMATION FOLLOWS ---
New trace stream is "/private1/oracle/trace_admin.trc"
New trace level is 6
--- TRACE CONFIGURATION INFORMATION ENDS ---

--- PARAMETER SOURCE INFORMATION FOLLOWS ---
Attempted load of system pfile source /private1/oracle/network/admin/sqlnet.ora
Parameter source was not loaded
Error stack follows:
NL-00405: cannot open parameter file

Attempted load of local pfile source /home/ginger/.sqlnet.ora
Parameter source loaded successfully

 -> PARAMETER TABLE LOAD RESULTS FOLLOW <-
Some parameters may not have been loaded
See dump for parameters which loaded OK
 -> PARAMETER TABLE HAS THE FOLLOWING CONTENTS <-
  TRACE_DIRECTORY_CLIENT = /private1/oracle
  trace_level_client = ADMIN
  TRACE_FILE_CLIENT = trace_admin
--- PARAMETER SOURCE INFORMATION ENDS ---

--- LOG CONFIGURATION INFORMATION FOLLOWS ---
Attempted open of log stream "/private1/oracle/sqlnet.log"
Successful stream open
--- LOG CONFIGURATION INFORMATION ENDS ---

Unable to get data from navigation file tnsnav.ora
local names file is /home/ginger/.tnsnames.ora
system names file is /etc/tnsnames.ora
initial retry timeout for all servers is 500 csecs
max request retries per server is 2
default zone is [root]
Using nncin2a() to build connect descriptor for (possibly remote) database.
initial load of /home/ginger/.tnsnames.ora
-<ERROR>- failure, error stack follows
-<ERROR>- NL-00405: cannot open parameter file
-<ERROR>-   NOTE: FILE CONTAINS ERRORS, SOME NAMES MAY BE MISSING

initial load of /etc/tnsnames.ora
-<ERROR>- failure, error stack follows
-<ERROR>- NL-00427: bad list
-<ERROR>-   NOTE: FILE CONTAINS ERRORS, SOME NAMES MAY BE MISSING

Inserting IPC address into connect descriptor returned from nncin2a().
Calling address: (DESCRIPTION=(CONNECT_DATA=(SID=trace)(CID=(PROGRAM=)(HOST=lala)
 (USER=ginger)))(ADDRESS_LIST=(ADDRESS=(PROTOCOL=ipc
 (KEY=bad_host))(ADDRESS=(PROTOCOL=tcp)(HOST=lavender)
 (PORT=1521))))
Getting local community information
Looking for local addresses setup by nrigla
No addresses in the preferred address list
TNSNAV.ORA is not present. No local communities entry.
Getting local address information
Address list being processed...
No community information so all addresses are "local"
Resolving address to use to call destination or next hop
Processing address list...
No community entries so iterate over address list
This a local community access
Got routable address information
Making call with following address information: (DESCRIPTION=(EMPTY=0)(ADDRESS=(PROTOCOL=ipc)(KEY=bad_host)))
Calling with outgoing connect data (DESCRIPTION=(CONNECT_DATA=(SID=trace)(CID=(PROGRAM=)(HOST=lala)
 (USER=ginger)))(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)
 (HOST=lavender)(PORT=1521))))
(DESCRIPTION=(EMPTY=0)(ADDRESS=(PROTOCOL=ipc)(KEY=bad_host)))
 KEY = bad_host
connecting...
opening transport...
-<ERROR>- sd=8, op=1, resnt[0]=511, resnt[1]=2, resnt[2]=0
-<ERROR>- unable to open transport
-<ERROR>- nsres: id=0, op=1, ns=12541, ns2=12560; nt[0]=511, nt[1]=2, nt[2]=0
connect attempt failed
Call failed...
Call made to destination
Processing address list so continuing
Getting local community information
Looking for local addresses setup by nrigla
No addresses in the preferred address list
TNSNAV.ORA is not present. No local communities entry.
Getting local address information
Address list being processed...
No community information so all addresses are "local"
Resolving address to use to call destination or next hop
Processing address list...
No community entries so iterate over address list
This a local community access
Got routable address information


Making call with following address information: (DESCRIPTION=(EMPTY=0)(ADDRESS=(PROTOCOL=tcp)
 (HOST=lavender)(PORT=1521)))
Calling with outgoing connect data (DESCRIPTION=(CONNECT_DATA=(SID=trace)(CID=(PROGRAM=)(HOST=lala)
 (USER=ginger)))(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)
 (HOST=lavender)(PORT=1521))))
(DESCRIPTION=(EMPTY=0)(ADDRESS=(PROTOCOL=tcp)
 (HOST=lavender)(PORT=1521)))
port resolved to 1521
looking up IP addr for host: lavender

-<FATAL?>-  *** hostname lookup failure! ***

-<ERROR>- nsres: id=0, op=13, ns=12545, ns2=12560; nt[0]=515, nt[1]=0, nt[2]=0
Call failed...
Exiting NRICALL with following termination result -1
-<ERROR>-  error from nricall
-<ERROR>-    nr err code: 12206
-<ERROR>-    ns main err code: 12545
-<ERROR>-    ns (2)  err code: 12560
-<ERROR>-    nt main err code: 515
-<ERROR>-    nt (2)  err code: 0
-<ERROR>-    nt OS   err code: 0
-<ERROR>- Couldn't connect, returning 12545

Most tracing is very similar to this. If you have a basic understanding of the events the components perform, you can identify the probable cause of an error in the text of the trace.

Note: Customers who have a beta version of the new Oracle Trace product installed on a Solaris or Sequent machine will see additional files in the trace directory beside the standard .TRC files. These .CDF and .DAT files are created by Oracle Trace. They are in an encoded binary format and are not readable without Oracle Enterprise Manager, which is not yet released. To save disk space, these files should be removed.

Prev Next

Library

Product

Contents

Index

*Trace Parameters Corresponding to*	*Configuration Files*	*Output Files*
Client	SQLNET.ORA	SQLNET.TRC
Server		SQLNET.TRC
TNSPING Utility		TNSPING.TRC
Names Control Utility		NAMESCTL.TRC
Listener	LISTENER.ORA	LISTENER.TRC
Interchange	INTCHG.ORA
Connection Manager		CMG.TRC
Pumps		PMP.TRC
Navigator		NAV.TRC
Names Server	NAMES.ORA	NAMES.TRC

*Parameters*	*Default*	*Values*	*Example (DOS client, UNIX server)*
TRACE_LEVEL_CLIENT	OFF	[OFF \| USER \|ADMIN]	TRACE_LEVEL_CLIENT=USER
TRACE_FILE_CLIENT	SQLNET.TRC	string	TRACE_FILE_CLIENT=CLIENT
TRACE_DIRECTORY_CLIENT	O/S specific	valid directory	TRACE_DIRECTORY_CLIENT= c:\NET\ADMIN
TRACE_UNIQUE_CLIENT	OFF	[ON\|OFF]	TRACE_UNIQUE_CLIENT=ON
LOG_FILE_CLIENT	SQLNET.LOG	string	LOG_FILE_CLIENT=CLIENT
LOG_DIRECTORY_CLIENT	O/S specific	valid directory	LOG_DIRECTORY_CLIENT=c:\NET\ADMIN
TRACE_LEVEL_SERVER	OFF	[OFF \| USER \| ADMIN]	TRACE_LEVEL_SERVER=ADMIN
TRACE_FILE_SERVER	SQLNET.TRC	string	TRACE_FILE_SERVER=unixsrv_2345.trc
TRACE_DIRECTORY_SERVER	O/S specific	valid directory	TRACE_DIRECTORY_SERVER=/tmp/trace
LOG_FILE_SERVER	SQLNET.LOG	string	LOG_FILE_SERVER=unixsrv.log
LOG_DIRECTORY_SERVER	O/S specific	valid directory	LOG_DIRECTORY_SERVER=/tmp/trace