ADRCI is a command-line tool that is part of the fault diagnosability infrastructure. ADRCI enables you to do the following:

• View diagnostic data within ADR

• Package incident and problem information into a zip file for transmission to Oracle Support Services

Diagnostic data includes incident and problem descriptions, trace files, dumps, health monitor reports, alert log entries, and so on.

ADRCI has a rich command set, and can be used in interactive mode or within scripts. In addition, ADRCI can run scripts of ADRCI commands in the same way that SQL*Plus runs scripts with SQL and PL/SQL commands.

To view trace files using ADRCI, enter ADRCI at a command line. The following are common ADRCI commands used to check a client:

adrci> SHOW ALERT
adrci> SHOW BASE -product client
adrci> SET BASE -product client
adrci> SHOW TRACEFILE
adrci> SHOW TRACE trace_file.trc
adrci> SHOW SPOOL

In the preceding commands, the SHOW ALERT command shows the log.xml file in a text editor, such as VI. The SHOW BASE -product client command displays the value of the ADR_BASE directory for the client. Use that value for client in the SET BASE command.

The following are common ADRCI commands used to check a server:

adrci> SHOW BASE
adrci> SHOW TRACEFILE
adrci> SHOW TRACE trace_file.trc

Other ADRCI command options are available for a more targeted Oracle Net trace file analysis. Type HELP at the ADRCI prompt for help documentation.

To start diagnosing server problems, you should answer the following questions:

• Is any other system such as a workstation or server able to connect to the server using Oracle Net?

• Has the server, database, or listener configuration remained the same for some time?

If you answered yes to either of the preceding questions, then go to "Diagnosing Client Problems".

If you are unsure, or answered no to any of the preceding questions, then use the tasks in this section to diagnose the problem. Diagnosing Oracle Net Services on the server involves the following tasks:

• Task 1, "Verify the Database is Running"

• Task 2, "Perform a Loopback Test"

Task 1   Verify the Database is Running

To check that the database is up, log in to the database and connect with a valid username and password. For example:

SQLPLUS system
Enter password: password

A message appears, confirming that you are connected with the database. If you receive the following errors, then ask the database administrator to assist you:

• ORA-1017: invalid U/P

• ORA-1034: Oracle not available

Task 2   Perform a Loopback Test

A loopback test uses Oracle Net to go from the database server back to itself, bypassing the Interprocess Communication (IPC) protocol. Many network protocols provide a means of testing network connections. The PING utility can be used with a TCP/IP network. Performing a successful loopback verifies that Oracle Net is functioning on the database server.

The following procedure describes how to perform a loopback test from the server to the database:

1. Ensure that the listener.ora, tnsnames.ora, and sqlnet.ora files exist in the correct locations, as described in "Using Localized Management".

2. Start Oracle Net Manager.

   See Also:

   "Using Oracle Net Manager to Configure Oracle Net Services"

3. In the navigator, expand the Directory or Local option.

4. Expand Service Naming to view the available network service and database names.

5. Select the network service name or database service.

6. Choose Command, and then select Test Net Service.

   Testing assumes the listener and database are running. If they are not, then see "Starting Oracle Net Listener and the Oracle Database Server" to start components.

   During testing, a Connection Test dialog box appears, providing status and test results. A successful test results in the following message:

   The connection test was successful.
   

   If the test was successful, then proceed to step 7.

   If the test was not successful, then do the following:

   1. Ensure the database and listener are running, and then click Test.

   2. Click Change Login to change the username and password for the connection, and then click Test.

   • If the loopback test passes, then go to "Diagnosing Client Problems".

   • If the loopback test continues to fail, then contact Oracle Support Services.

7. Click Close to close the Connect Test dialog box.

Verify at least one of the following statements. This will help you decide if it is a client problem.

• The database server passed a loopback test, showing the connection worked.

• Other computers connect using Oracle Net Services to the same database.

• Connections from this workstation worked before making changes on this computer, such as the installation of a new product or modification to the network configuration.

The following procedure describes how to perform diagnostics on the client:

1. Check that you have installed the same protocol support that was installed on the database server.

   On Linux and UNIX platforms you can use the ADAPTERS utility to verify protocol support. On the database server, run the following command from the ORACLE_HOME/bin directory to display the protocol support, naming methods, and security options linked with the oracle executable:

   adapters ./oracle
   

   The adapters utility displays output similar to the following:

   Installed Oracle Net transport protocols are:
   
       IPC
       BEQ
       TCP/IP
       SSL
       RAW
       SDP/IB
   
   Installed Oracle Net naming methods are:
   
       Local Naming (tnsnames.ora)
       Oracle Directory Naming
       Oracle Host Naming
       NIS Naming
   
   Installed Oracle Advanced Security options are:
   
       RC4 40-bit encryption
       RC4 56-bit encryption
       RC4 128-bit encryption
       RC4 256-bit encryption
       DES40 40-bit encryption
       DES 56-bit encryption
       3DES 112-bit encryption
       3DES 168-bit encryption
       AES 128-bit encryption
       AES 192-bit encryption
       AES 256-bit encryption
       MD5 crypto-checksumming
       SHA crypto-checksumming (for FIPS)
       SHA-1 crypto-checksumming
       Kerberos v5 authentication
       RADIUS authentication
   

   On the client, run the adapters command from the ORACLE_HOME/bin directory to display the configured Oracle protocol support, naming methods, and security options. The ADAPTERS utility displays output similar to the following:

   Installed Oracle Net transport protocols are:
   
       IPC
       BEQ
       TCP/IP
       SSL
       RAW
       SDP/IB
       Exadirect
   
   Installed Oracle Net naming methods are:
   
       Local Naming (tnsnames.ora)
       Oracle Directory Naming
       Oracle Host Naming
      
   Installed Oracle Advanced Security options are:
   
       RC4 40-bit encryption
       RC4 56-bit encryption
       RC4 128-bit encryption
       RC4 256-bit encryption
       DES40 40-bit encryption
       DES 56-bit encryption
       3DES 112-bit encryption
       3DES 168-bit encryption
       AES 128-bit encryption
       AES 192-bit encryption
       AES 256-bit encryption
       MD5 crypto-checksumming
       SHA-1 crypto-checksumming
       Kerberos v5 authentication
       RADIUS authentication

   Note:

   RAW is an internal protocol used by Oracle Net.

   See Also:

   Oracle Database Administrator's Reference for additional information about the adapters utility

2. Check base connectivity for underlying network transport. Oracle Net technology depends on the underlying network for a successful connection.

   Table 16-7

   Protocol	Verify that you can...
   TCP/IP	Use terminal emulation or file transfer utilities, (PING, FTP, TELNET) from the client to the database server.
   Named Pipes	See other computers or servers on the Microsoft network. Ensure that you are able to share drives within the network.

3. Ensure that the Oracle Net foundation layer and the appropriate Oracle protocol support are present by verifying that all Oracle Net Services software has been installed for the client.

4. Ensure that the client computer has the tnsnames.ora and the sqlnet.ora files in the correct locations.

   See Also:

   "Using Localized Management"

   If any other working client computers are connecting to the selected Oracle Database, then back up your existing files and copy both the working tnsnames.ora and sqlnet.ora files from the working client computer to the non-working clients. This eliminates the possibility of errors in the files.

5. Test the Oracle Net foundation layer. You can test using the following command to connect to SQL*Plus:

   SQLPLUS user/password@connect_string

   Note:

   Do not use the TNSPING utility. The TNSPING utility works like the TCP/IP ping utility and does not create and open a socket, nor does it connect with the listener. It only shows that the listener is present on the database server.

6. If the connection still fails, then do the following:

   1. Use tracing, as described in section "Tracing Error Information for Oracle Net Services".

   2. Check the Oracle Support Services website for a specific diagnostics bulletin on the error received.

   3. Contact Oracle Support Services.

This message indicates that an error has occurred on the database server.

Check the alert_sid.log file on the server. An unexpected end of file was processed on the communication channel. This may be an indication that the communications link may have gone down at least temporarily, or it may indicate that the server has gone down.You may need to modify your retransmission count.

This message indicates that a connection to a database or other service was requested using a connect identifier, and the connect identifier specified could not be resolved into a connect descriptor using one of the naming methods configured. For example, if the type of connect identifier used was a network service name then the network service name could not be found in a naming method repository, or the repository could not be located or reached.

Perform the following steps:

1. Check the type of naming adapters listed in the NAMES.DIRECTORY_PATH parameter in the sqlnet.ora file. If none are configured, then use the adapters command to determine which adapters are in use. The following example shows the adapters:

   $ adapters
                ...
        Installed Oracle Net naming methods are:
    
            Local Naming (tnsnames.ora)
            Oracle Directory Naming
            Oracle Host Naming
            NIS Naming
   

   The network service name given in the connect string should be defined for at least one of the naming methods.

2. Check the resolution path for each adapter for possible problems. For example, ensure that the name given in the connect string is correct and complete, using the full name of the network service if necessary.

In addition to the preceding steps, perform the steps depending on your naming methods:

• ORA-12154 Error When Using the Local Naming Method
  
• ORA-12154 Error When Using the Directory Naming Method
  
• ORA-12154 Error When Using the Easy Connect Naming Method
  
• ORA-12154 Error When Using the External Naming Method
  

This message indicates that the client failed to establish a connection and complete authentication in the time specified by the SQLNET.INBOUND_CONNECT_TIMEOUT parameter in the sqlnet.ora file. This error may be a result of network or system delays, or it may indicate that a malicious client is trying to cause a denial-of-service attack on the database server.

• If the error occurred due to system or network delays that are normal for the particular environment, then perform the following steps:

  1. Turn on tracing to determine which clients are timing out.

     See Also:

     "Tracing Error Information for Oracle Net Services"

  2. Reconfigure the SQLNET.INBOUND_CONNECT_TIMEOUT, SQLNET.SEND_TIMEOUT, or SQLNET.RECV_TIMEOUT parameters in the sqlnet.ora file to larger values.

• If you suspect a malicious client, then perform the following steps:

  1. Restrict access to the client. You can configure parameters for access rights in the sqlnet.ora file.

  2. Locate the IP address of the client in the sqlnet.log file on the database server to identify the source. Keep in mind that an IP address can be forged.

     For example, the following sqlnet.log excerpt shows a client IP address of 192.0.2.35.

     Fatal NI connect error 12170.
     
     VERSION INFORMATION:
     TNS for Linux: Version 18.0.0.0.0
     Oracle Bequeath NT Protocol Adapter for Linux: Version 18.0.0.0.0
     TCP/IP NT Protocol Adapter for Linux: Version 18.0.0.0.0
       Time: 03-JAN-2018 13:51:12
       Tracing to file: /ora/trace/svr_13279.trc
       Tns error struct:
         nr err code: 0
         ns main err code: 12637
         TNS-12637: Packet receive failed
         ns secondary err code: 12604
         nt main err code: 0
         nt secondary err code: 0
         nt OS err code: 0
       Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=192.0.2.35)(PORT=52996))
     

     If the time out occurs before the IP address can be retrieved by the database server, then enable listener tracing to determine the client that made the request.

These messages indicate that the listener failed to start the Oracle program. Possible reasons include:

• The maximum number of processes allowed for a single user was exceeded

• The listener does not have execute permission on the Oracle program

• The associated Microsoft Windows service is not started

In some cases, these errors can be caused by the same conditions which cause the following errors:

• TNS-12549 or ORA-12549

• TNS-00519

• TNS-12540 or ORA-12540

• TNS-00510

• TNS-12560 or ORA-12560

Perform the appropriate action:

• Increase the number of processes by setting the PROCESSES parameter in the database initialization file to a larger value.

• Check the listener.log file for detailed error stack information.

This message indicates that the listener received a request to establish a connection to a database or other service. The connect descriptor received by the listener specified a service name for a service (usually a database service) that has either not yet dynamically registered with the listener or has not been statically configured for the listener. This may be a temporary condition such as after the listener has started, but before the database instance has registered with the listener.

Perform the following steps:

1. Wait a moment, and then try to connect a second time.

2. Check which services are currently known by the listener by running the Listener Control utility STATUS or SERVICES command.

3. Check that the SERVICE_NAME parameter in the connect descriptor specifies a service name known by the listener.

4. Check for an event in the listener.log file.

   See Also:

   • "Determining the Current Status of a Listener" and "Monitoring Services of a Listener"

   • "Analyzing Listener Log Files"

This message indicates that the type of service handler requested by the client is incorrect or not registered for the requested SERVICE_NAME/INSTANCE_NAME parameters, or the database instance is not registered with the listener.

If you suspect the problem is the wrong type of service handler, then perform the following steps:

1. If (server=value) is set in the connect descriptor, then ensure that the value is set to the appropriate service handler type for the database, that is, dedicated for dedicated server or shared for dispatchers. You can use the Listener Control utility SERVICES command to see what service handlers are currently registered with the listener.

2. If the USE_DEDICATED_SERVER parameter is set to ON in the sqlnet.ora file, then ensure the database is configured to use dedicated servers. If it is not, then set this parameter to OFF.

3. Ensure that the database instance is running. If the instance not running, then start it so that it can register with the listener.

This message indicates that the instance name in the connect descriptor is incorrect, or the database instance is not registered with the listener.

Perform the following steps:

1. Ensure the service name specified in the connect descriptor is correct.

2. Ensure the database instance is running. If the instance not running, then start it so that it can register with the listener. You can use the Listener Control utility SERVICES command to see what instances are currently registered with the listener.

   See Also:

   "Monitoring Services of a Listener" for additional information about SERVICES command

This message indicates that the client failed to complete its connect request in the time specified by the INBOUND_CONNECT_TIMEOUT_listener_name parameter in the listener.ora file. This error may be a result of network or system delays, or it may indicate that a malicious client is trying to cause a denial-of-service attack on the listener.

• If the error occurred due to system or network delays that are normal for the particular environment, then reconfigure the INBOUND_CONNECT_TIMEOUT_listener_name parameter in listener.ora to a larger value.

• If you suspect a malicious client, then perform the following steps:

  1. Locate the IP address of the client in the listener.log file to identify the source. Keep in mind that an IP address can be forged.

     For example, the following listener.log file excerpt shows a client IP address of 192.0.2.35.

     03-MAY-2012 16:42:35 * <unknown connect data> *
     (ADDRESS=(PROTOCOL=tcp)(HOST=192.0.2.35)(PORT=53208)) * establish *
     <unknown sid> * 12525
     TNS-12525: TNS:listener has not received client's request in time
     allowed
     TNS-12604: TNS: Application timeout occurred
     

  2. Restrict access to the client. You can configure parameters for access rights in the sqlnet.ora file.

This message indicates that the protocol specific parameters in the ADDRESS section of the designated connect descriptor are incorrect.

Correct the protocol address.

These messages indicate that an internal limit has been exceeded. Possible limits include the following:

• Number of open connections that Oracle Net can process simultaneously

• Number of memory buffers that can be used simultaneously

• Number of processes a particular database instance is allowed

The first two are examples of hard limits. The third is an example of a limit which can be increased by setting PROCESSES parameter in the database initialization file to a larger value. In this case, a TNS-12500 or ORA-12500 error is also returned. In some cases, these errors can be caused by the same conditions which cause TNS-12549 or ORA-12549, and TNS-00519 errors.

Wait for the open connections to close and retry. If the error persists, then check the sqlnet.log or listener.log file for detailed error stack information.

These messages indicate that the connection request could not be completed because the listener is not running.

Perform the following actions:

• Ensure the supplied destination address matches one of the addresses used by the listener.

• Verify the listener is running at the address specified by the request.

• Ensure the listener is listening on the host and port specified by the request.

• Verify the client is pointing to the listener.

These messages indicate that a quota or hard limit imposed by the operating system has been exceeded.

Possible limits include:

• The maximum number of processes allowed for a single user

• The operating system is running low on paging space

Perform the appropriate action:

• Increase the number of processes by setting the PROCESSES parameter in the database initialization file to a larger value.

• Check the sqlnet.log or listener.log file for detailed error stack information, such as an operating system error code to help identify which quota has been exceeded.

These messages indicate that there was an error when using a particular protocol. This error may be due to incorrect configuration of an ADDRESS parameter or may occur due to errors returned from the underlying protocol or operating system interface.

In some cases, these errors are caused by the same conditions which cause TNS-00510, TNS-00519, TNS-12540, ORA-12540, TNS-12549 or ORA-12549 errors.

These errors occur on Microsoft Windows systems only. Perform the following actions:

1. Select Run from the Microsoft Windows Start menu.

2. Enter MSCONFIG in the Open field.

3. Go to the Services tab.

4. Enable OracleServicesid if it is disabled.

5. Restart the computer.

6. Check that Oracle Services started.

Directory naming issues associated with connectivity errors for database service or network service name entries in a directory server require analysis of the data. You can analyze the data contained within a directory server with the ldifwrite command line tool. The ldifwrite tool is an Oracle Internet Directory tool.

The ldifwrite tool can be used to convert all or part of the information residing in a directory server to LDIF. The ldifwrite tool performs a subtree search, including all entries following the specified distinguished name (DN), including the DN itself.

The ldifwrite tool syntax is as follows:

ldifwrite -c net_service_name/database_service -b base_DN -f ldif_file 

Table 16-8 lists ldifwrite tool arguments and descriptions for each.

The following example writes all the directory naming entries under dc=us,dc=example,dc=com to the output1.ldi file:

ldifwrite -c ldap -b "dc=us,dc=example,dc=com" -f output.ldif

The following questions can help diagnose a problem:

• Do all computers have a problem, or is it just one?

  If one computer works and another does not, and the same software (Oracle and third-party products) is installed on each computer, then, if possible, swap out the network cables to see if the problem occurs on the second client. If it does occur, then it indicates that the problem has something to do with the client/server connection and is not local to the client.

• What kind of connections exist between the client and the server, for example, X.25, ISDN, or leased line?

  Sniffers and LAN analyzers are useful for locating intermittent connection failures, and detecting time outs and resent packets. You can also see which side is waiting for a response.

Log files provide information contained in an error stack. An error stack refers to the information that is produced by each layer in an Oracle communications stack as the result of a network error.

The error stack components are described in Table 16-9.

• Understanding Error Stack Messages
  

Each Oracle Net Services component produces its own log file. When using ADR, the default, the log file names are log.xml in the appropriate alert directory. Table 16-10 lists the default log file names and lists the components that generate the log files that appear in the ADR/diag/instance_name/trace directory.

The maximum size and number of text log files can be configured for Oracle Network components such as Oracle Net Listener, Oracle Connection Manager, and Global Service Manager.

Parameters that control logging, including the type and amount of information logged, and the location where the files are stored, are set in the configuration file of each network component as described in Table 16-11.

This section contains the following topics:

• sqlnet.ora Log Parameters
  
• listener.ora Log Parameters
  
• cman.ora Log Parameters
  

You configure logging parameters for the sqlnet.ora file with Oracle Net Manager and for the listener.ora file with either Oracle Enterprise Manager Cloud Control or Oracle Net Manager. You must manually configure cman.ora file logging parameters.

• Setting Parameters for the sqlnet.ora File Using Oracle Net Manager
  
• Setting Parameters for the listener.ora File Using Oracle Enterprise Manager Cloud Control
  
• Setting Parameters for the listener.ora File Using Oracle Net Manager
  

You can set logging during control utility runtime. Setting logging with a control utility does not set parameters in the *.ora files, and the setting is only valid for the control utility session.

The following settings can be set for a control utility:

• For a listener, use the SET LOG_FILE and SET LOG_DIRECTORY commands from the Listener Control utility.

• For an Oracle Connection Manager, use the SET LOG_DIRECTORY, SET LOG_LEVEL, and SET EVENT commands from the Oracle Connection Manager control utility.

The following procedure describes how to use a log file to diagnose a network error:

1. Review the log file for the most recent error number received from the application. This is usually the last entry in the log file.

2. Starting from the bottom of the file, locate the first nonzero entry in the error report. This is usually the actual cause.

3. If that error does not provide the information, then review the next error in the log until you locate the correct error information.

4. If the cause of the error is still not clear, then turn on tracing and repeat the command that produced the error message.

This section describes what is recorded in the listener log file.

• Listener Log Audit Trail Information
  
• Listener Service Registration Event Information
  
• Listener Direct Hand-Off Information
  
• Listener Subscription for ONS Node Down Event Information
  
• Listener Oracle Clusterware Notification Information
  

Oracle Connection Manager generates four types of log files, one each for its listener, gateway, CMADMIN processes, and alerts. The alert log file is a chronological record of all critical errors. In addition to logging critical errors, the alert log captures information about instance startup and shutdown. It also records the value of all configuration parameters at the beginning and end of a session.

Example 16-9 and Example 16-10 are representative of the CMADMIN and gateway log files. Table 16-16 explains log entries. Each entry consists of a timestamp and an event. You can configure the cman.ora file to log events for the following categories:

• Initialization and termination

• Memory operations

• Connection handling

• Process management

• Registration and load update

• Events related to CMADMIN wakeup queue

• Gateway timeouts

• Command processing

• Events associated with connection control blocks

Use the SET EVENT command to specify which events to log.

Example 16-9 shows a typical CMADMIN log.

-------------------------------
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:40)(EVENT=Parameter list)
    (listener_address=(address=(protocol=tcp)(host=sales1)(port=1574)))
    (aso_authentication_filter=OFF)
    (connection_statistics=ON)
    (log_directory=/home/user/network/admin/log)
    (log_level=support)
    (max_connections=256)
    (idle_timeout=5)
    (inbound_connect_timeout=0)
    (session_timeout=20)
    (outbound_connect_timeout=0)
    (max_gateway_processes=1)
    (min_gateway_processes=1)
    (password=OFF)
    (trace_directory=/home/user/network/admin/log)
    (trace_level=off)
    (trace_timestamp=OFF)
    (trace_filelen=0)
    (trace_fileno=0)
)
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:40)(EVENT=Shared Memory Size)
(BYTES=82524))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:40)(EVENT=GMON Attributes validated)
(Type=Information))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:40)(EVENT=NS Listen Successful)
((ADDRESS=(PROTOCOL=tcp)(HOST=usunnae16)(PORT=55878))))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:44)(EVENT=Received command)(CMD=verify
password))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:44)(EVENT=Received command)
(CMD=version))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:44)(EVENT=Received command)
(CMD=show status))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:44)(EVENT=Failed to get procedure id))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:49:12)(EVENT=Received command)(CMD=verify
password))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:49:15)(EVENT=Failed to get procedure id))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:49:29)(EVENT=Received command)(CMD=verify
password))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:49:46)(EVENT=Failed to get procedure id))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:49:50)(EVENT=Received command)(CMD=verify
password))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:49:50)(EVENT=Received command)
(CMD=probe monitor))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:49:50)(EVENT=Received command)
(CMD=shutdown normal))
-------------------------------

Example 16-10 shows a typical gateway log file.

-------------------------------
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:41)(EVENT=NS Initialised))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:41)(EVENT=Memory Allocated)
(BYTES=1024))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:41)(EVENT=NCR Initialised))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:41)(EVENT=Connected to Monitor))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:41)(EVENT=State Change from Empty to 
Init))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:41)(EVENT=Memory Allocated)
(BYTES=251904))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:41)(EVENT=Memory Allocated)
(BYTES=2048))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:41)(EVENT=CCB Initialised))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:41)(EVENT=Started Listening))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:41)(EVENT=State Change from Init to 
Ready))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:46:47)(EVENT=Housekeeping))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:06)(EVENT=Ready)(CONN NO=0))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:06)(EVENT=Ready)(CONN NO=0))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:07)(EVENT=Housekeeping))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:12)(EVENT=Housekeeping))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:13)(EVENT=Idle Timeout)(CONN NO=0))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:17)(EVENT=Housekeeping))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:22)(EVENT=Housekeeping))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:25)(EVENT=Ready)(CONN NO=0))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:25)(EVENT=Ready)(CONN NO=0))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:27)(EVENT=Housekeeping))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:30)(EVENT=Idle Timeout)(CONN NO=0))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:32)(EVENT=Housekeeping))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:37)(EVENT=Housekeeping))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:42)(EVENT=Ready)(CONN NO=0))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:42)(EVENT=Ready)(CONN NO=0))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:42)(EVENT=Housekeeping))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:47)(EVENT=Housekeeping))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:52)(EVENT=Housekeeping))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:48:57)(EVENT=Housekeeping))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:49:02)(EVENT=Session Timeout)(CONN NO=0))
(LOG_RECORD=(TIMESTAMP=08-MAY-2012 08:49:02)(EVENT=Housekeeping))
-------------------------------

Table 16-16 shows the log file entries and their descriptions.

Each Oracle Net Services component produces its own trace file. Table 16-17 provides the default trace file names and lists the components that generate the trace files.

Parameters that control tracing, including the type and amount of information trace, and the location where the files are stored, are set in the configuration file of each network component as described in Table 16-18.

This section contains the following topics:

• cman.ora Trace Parameters
  
• listener.ora Trace Parameters
  
• sqlnet.ora Trace Parameters
  
• Setting Tracing Parameters in Configuration Files
  

You can set tracing during control utility runtime. Setting tracing with a control utility does not set parameters in the *.ora files. The setting is only valid for the session of the control utility:

• For the listener, use the SET TRC_DIRECTORY, SET TRC_FILE, and SET TRC_LEVEL commands from the Listener Control utility.

• For Oracle Connection Manager, use the SET TRACE_DIRECTORY and SET TRACE_LEVEL, and SET TRACE_TIMESTAMP commands from the Oracle Connection Manager control utility.

Trace files can help Oracle Support Services diagnose and troubleshoot network problems. This section explains how to perform basic analysis of trace files.

• Flow of Data Packets Between Network Nodes
  
• Oracle Net Data Packet Formats
  
• Pertinent Oracle Net Trace Error Output
  

Oracle Net Services provides a tool called the Trace Assistant to help understand the information provided in trace files by converting existing lines of trace file text into a more readable paragraph. The Trace Assistant works only with level 16 (support) Oracle Net Services trace files.

• Trace Assistant Syntax
  
• Packet Examples
  
• Two-Task Common (TTC) Packet Examples
  
• Connection Example
  
• Statistics Example