| Oracle9i Net Services Administrator's Guide Release 2 (9.2) Part Number A96580-02 |
|
|
View PDF |
| Oracle9i Net Services Administrator's Guide Release 2 (9.2) Part Number A96580-02 |
|
|
View PDF |
Oracle Net Services provides methods for understanding and resolving network problems through the use of log and trace files. These files keep track of the interaction between network components as errors occur. Evaluating this information will help you to diagnose and troubleshoot even the most complex network problems.
This chapter describes common network errors and outlines procedures for resolving them. It also describes methods for logging and tracing error information to diagnose and troubleshoot more complex network problems. This chapter contains these topics:
If an attempt to make a basic peer-to-peer (single protocol network) connection returns an ORA Error, this section may help you diagnose the cause of the problem.
Any underlying fault, noticeable or not, is reported by Oracle Net Services with an error number or message that is not always indicative of the actual problem. This section helps you determine which parts of Oracle Net Services do function properly rather than the parts that do not work. It also helps you to decide in which of the following categories the fault belongs:
Testing the various network layers progressively should in most cases uncover any problem.
|
Note: You may need assistance from your server administrator to follow the instructions in this section. |
Answer the following questions:
If you answered YES to any of the preceding questions/statements, then skip this section and continue to "Client Diagnostics".
If you are unsure, or answered NO to any of the preceding questions, then continue.
Diagnosing Oracle Net Services on the server involves the following tasks:
To check that the database is up, login to the database and connect with a valid username and password. For example:
SQLPLUS system/manager
A message appears, confirming that you are connected with the database. If you receive the following errors, ask your Database Administrator to assist you:
To perform a loopback test from the server to the database:
listener.ora, tnsnames.ora, and sqlnet.ora files exist in the correct locations, as described in "Localized Configuration File Support".At this point, you know the serverside listener works properly, because you could verify at least one of the following statements:
To perform diagnostics on the client:
On UNIX you can use the ADAPTERS utility to verify protocol support. On the database server, run the adapters 'which oracle' command from $ORACLE_HOME/bin to display the protocol support, naming methods, and security options linked with the oracle executable. The adapters utility displays output similar to the following:
Oracle Net transport protocols linked with ./oracle are: IPC BEQ TCP/IP SSL RAW Oracle Net naming methods linked with ./oracle are: Local Naming (tnsnames.ora) Oracle Directory Naming Oracle Host Naming Oracle Names Server Naming NIS Naming Oracle Advanced Security options linked with ./oracle 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 CyberSAFE authentication RADIUS authentication ENTRUST authentication
On the client, run the adapters command from $ORACLE_HOME/bin 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 Installed Oracle Net naming methods are: Local Naming (tnsnames.ora) Oracle Directory Naming Oracle Host Naming Oracle Names Server 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-1 crypto-checksumming Kerberos v5 authentication CyberSAFE authentication RADIUS authentication
| 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 |
tnsnames.ora and the sqlnet.ora files exist in the correct locations.
If you have any other working client computers connecting to the selected Oracle database, back up your existing files and copy both the working tnsnames.ora and sqlnet.ora files from the working computer onto the non-working client workstations. This eliminates the possibility of errors in the files.
http://support.oracle.com for a specific diagnostics bulletin on the error receivedDue to the complexity of network communications, network errors may originate from a variety of sources, for a variety of reasons. If an error occurs, applications such as SQL*Plus, that depend on network services from Oracle Net Services, will normally generate an error message.
A list of the most common network error messages follows:
ORA-12154: TNS:could not resolve service nameORA-12170: TNS:Connect timeout occurredORA-12198: TNS:could not find path to destinationORA-12203: TNS:unable to connect to destinationORA-12224: TNS:no listenerORA-12514: TNS:listener could not resolve SERVICE_NAME given in connect descriptorORA-12520: TNS:listener could not find available handler for requested type of serverORA-12521: TNS:listener could not resolve INSTANCE_NAME given in connect descriptorORA-12525: TNS:listener has not received client's request in time allowedORA-12533: TNS:illegal ADDRESS parametersORA-12545: TNS:name lookup failureORA-12560: TNS:protocol adapter errorORA-3113: TNS:End of file on communication channelORA-3121: No interface driver connection - function not performed
| See Also:
Oracle9i Database Error Messages for a complete listing of error messages |
Cause: Oracle Net could not locate the net service name specified in the tnsnames.ora configuration file.
Action: Perform these steps:
tnsnames.ora file exists.
| See Also:
"Localized Configuration File Support" for configuration file location information |
tnsnames.ora file.tnsnames.ora file, verify that the net service name specified in your connect string is mapped to a connect descriptor.sqlnet.ora file.sqlnet.ora file contains a NAMES.DEFAULT_DOMAIN parameter. If this parameter does not exist, you must specify the domain name in your connect string.Cause: Oracle Net could not locate the database service name or net service name specified in the directory server.
Action: Perform these steps:
| See Also:
Chapter 8, "Setting Up Directory Server Usage" for directory setup instructions |
sqlnet.ora file includes the following entry:
NAMES.DIRECTORY_PATH=(ldap, other_naming_methods)
Cause: 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.
| See Also:
"Configuring the Listener and the Oracle Database To Limit Resource Consumption By Unauthorized Users" for further information about setting the |
Action: If the error occurred due to system or network delays that are normal for the particular environment, then perform these steps:
SQLNET.INBOUND_CONNECT_TIMEOUT parameter in sqlnet.ora to a larger value.
If you suspect a malicious client, then perform these steps:
sqlnet.log file on the database server to identify the source.
For example, the following sqlnet.log excerpt shows a client IP address of 10.10.150.35.
Fatal NI connect error 12170. VERSION INFORMATION: TNS for Solaris: Version 9.2.0.2.0 - Production Oracle Bequeath NT Protocol Adapter for Solaris: Version 9.2.0.2.0 - Production TCP/IP NT Protocol Adapter for Solaris: Version 9.2.0.2.0 - Production Time: 03-JUL-2002 13:51:12 Tracing to file: /ora9i/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=10.10.150.35)(PORT=52996))
Beware that an IP address can be forged.
If the timeout occurs before the IP address can be retrieved by the database server, then enable listener tracing to determine the client that made the request.
sqlnet.ora file.
Cause: The client cannot find the desired database.
Action: Perform these steps:
ADDRESS parameters in the connect descriptor.tnsnames.ora file is stored in the correct directory.
| See Also:
"Localized Configuration File Support" for configuration file location information |
lsnrctlLSNRCTL> STATUS [listener_name]
listener_name is the name of the listener defined in the listener.ora file. It is not necessary to identify the listener if you are using the default listener, named LISTENER.
If the output indicates the listener is not running, try starting it with the command:
LSNRCTL> START [listener_name]
Cause: ORA-12203 error is a generic error that often shields secondary errors.
Action: Check the latest sqlnet.log file for secondary ORA messages.
Cause: An invalid net service name was supplied in the connect string.
Action: Verify that the net service name supplied in the connect string exists in the tnsnames.ora file or directory server and the ADDRESS information for that net service name is valid. Ask yourself the following questions:
Cause: The tnsnames.ora file is not located in the proper directory.
Action: Make sure that the tnsnames.ora file is in the proper location.
| See Also:
"Localized Configuration File Support" for configuration file location information |
Cause: The (HOST=server_name) parameter for TCP/IP addresses is not consistent on the client and server computers.
Action: Ensure that the values for these parameter are the same on the server and client.
For TCP/IP, make sure that the HOST parameter in listener.ora on the server and in the tnsnames.ora file on the client point to the same name, or at least to names that are then translated to the same IP address by each system. This is especially important for servers with multiple IP addresses assigned to the various network interfaces on the server.
Cause: The destination system's listener is not listening.
Action: Verify that the remote system's listener is running. Enter:
lsnrctlLSNRCTL> STATUS [listener_name]
listener_name is the name of the listener defined in the listener.ora file. It is not necessary to identify the listener if you are using the default listener, named LISTENER.
If the output indicates the listener is not running, try starting it with the command:
LSNRCTL> START [listener_name]
Cause: There are underlying network transport problems.
Action: Use the utilities supplied with the underlying networking protocol to verify that the protocol itself is functional. For example, with TCP/IP, try to ping the remote system.
Cause: The incorrect Oracle protocol for the selected networking protocol is installed. A missing protocol support driver usually produces the following errors in the sqlnet.log file or any client trace file:
Action: Check that you have installed the appropriate Oracle protocol. On UNIX, you can run the ADAPTERS utility.
Cause: The connection request could not be completed because the listener is not running.
Action: Perform these steps:
Cause: The protocol specific parameters in the ADDRESS section of the designated connect descriptor are incorrect.
Action: Correct the protocol address.
| See Also:
Oracle9i Net Services Reference Guide for correct protocol syntax |
Cause: The service name specified in the connect descriptor is incorrect, or the database service is not registered with the listener.
Action: Perform these steps:
SERVICE_NAME specified in the connect descriptor is correct.SERVICES command to see what services are currently registered with the listener.
Cause: The type of service handler requested by the client is incorrect or not registered for the requested SERVICE_NAME/INSTANCE_NAME, or the database instance is not registered with the listener.
Action: If you suspect the problem is the wrong type of service handler, perform these steps:
(server=value) is set is in the connect descriptor, 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.
USE_DEDICATED_SERVER is set to ON in the sqlnet.ora file, then ensure the database is configured to use dedicated servers. If it is not, set this parameter to off.Cause: The INSTANCE_NAME in the connect descriptor is incorrect, or the database instance is not registered with the listener.
Action: Perform these steps:
SERVICES command to see what instances are currently registered with the listener.
Cause: 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.
| See Also:
"Configuring the Listener and the Oracle Database To Limit Resource Consumption By Unauthorized Users" for further information about setting the |
Action: 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 these steps:
listener.log to identify the source.
For example, the following listener.log excerpt shows a client IP address of 10.10.150.35.
03-JUL-2002 16:42:35 * <unknown connect data> * (ADDRESS=(PROTOCOL=tcp)(HOST=10.10.150.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
Beware that an IP address can be forged.
sqlnet.ora file.
Cause: The listener on the remote node cannot be contacted.
Action: Perform these steps:
ADDRESS in the tnsnames.ora file and the listener.ora file is correct.lsnrctlLSNRCTL> STATUS [listener_name]
listener_name is the name of the listener defined in the listener.ora file. It is not necessary to identify the listener if you are using the default listener, named LISTENER.
If the output indicates the listener is not running, try starting it with the command:
LSNRCTL> START [listener_name]
Action: The listener was unable to start a process connecting the user to the database server.
Cause: Perform these steps:
Cause: An error has occurred on the database server.
Action: Check the alert_sid.log on the server. The location of alert_sid.log is specified by the BACKGROUND_DUMP_DEST initialization parameter.
Cause: 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; it may indicate that the server has gone down.
Action: You may need to modify your retransmission count.
Cause: A SQL*Net version 1 prefix was erroneously used in the connect string.
Action: Do not use the following prefixes in the connect string.
Cause: The username and password were specified from a client computer that had no local Oracle database installed.
Action: Specify a connect string.
Directory naming issues associated with connectivity errors such as ORA-12154, ORA-12203, or ORA-12224 for database service or net 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.
ldifwrite enables you to convert all or part of the information residing in a directory server to LDAP Data Interchange Format (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 -cnet_service_name/database_service-bbase_DN-fldif_file
The following example writes all the directory naming entries under dc=us,dc=acme,dc=com to the output1.ldi file:
ldifwrite -c ldap -b "dc=us,dc=acme,dc=com" -f output.ldif
Errors in the region load operation will be reported in the Oracle Names server log file (names.log). These errors may range from failure to contact the directory server to errors with the query for all, some, or one of the records.
Some directories, such as Oracle Internet Directory, have limits on ldapsearch operations. There are settings in the directory server that limit the number of objects returned by the search and the amount of time spent performing a search.
The size limit specifies how many objects can be returned from a search. The default limit is 1000. If this limit is exceeded, you will see the following errors in the names.log file:
NNO-00062: cannot load domain data from configuration database NNO-00850: Error: LDAP query returns 4
You can also use the ldapsearch command line tool to mimic what the Oracle Names server will do when it loads its region. The following syntax shows loading data from DN (dn:dc=acme,dc=com):
ldapsearch -p 389 -h host -b "dc=acme,dc=com"
"(objectclass=orclNetService)(objectclass=orclService)"
After returning the allowed number of object, ldapsearch returns the following error message:
ldapsearch: Sizelimit exceeded
You can modify the size limit using the following sample LDIF file output. Enter the appropriate DN. In addition, set orclsizelimit high enough to allow for the number of databases defined in the region in the directory server, with a little room for future expansion.
dn: changetype: modify replace: orclsizelimit orclsizelimit: 5000
The time limit specifies the amount of time that can be spent performing a search. The default time limit is 10 seconds. Ten seconds is sufficient to query for roughly 1,000 object, which is sufficient for most searches. If the query exceeds the time limit, you will see the following errors in the names.log file:
NNO-00062: cannot load domain data from configuration database NNO-00850: Error: LDAP query returns 105
You can modify the time limit using the following sample LDIF file output. Enter the appropriate DN.
dn: changetype: modify replace: orcltimelimit orcltimelimit: 20
The time limit is applied at both the directory server and API levels. Therefore, in addition to resetting the directory server time limit, you will also need to set the TIMEOUT subparameter of NAMES.ADMIN_REGION. For example:
NAMES.ADMIN_REGION= (REGION= (TIMEOUT=20) (TYPE=ldap) (HOST=ldap_server) (PORT=389) (SUBTREE=(BASE=dc=acme,dc=com)))
Here are some tips you may find helpful when you are having difficulty diagnosing network problems:
This eliminates any internal lookup problems and make the connection slightly faster.
For example, change the
(HOST=server_name) line in the tnsnames.ora file with the internet address, for example (HOST=198.32.3.5).
Perform a loopback test on the server as described in "Testing Configuration on the Database Server". If the test passes, ftp the tnsnames.ora and sqlnet.ora files to the client.
If it is a wide area network (WAN), identify any intermediate systems that may not work correctly. If all computers are fine, the problem may be a timing issue.
Timing issues are associated with ORA-12203, ORA-12535, or ORA-12547 errors in the client log files.
To resolve this, try speeding up the connection by using exact addresses instead of names and increase the CONNECT_TIMEOUT_listener_name parameter in the listener.ora file. The default value for this parameter is 10 seconds.
SQL*Plus may work, but CASE tools may not. If you determine the problem is a data volume issue, try to transfer a large (5 MB) file with the base connectivity.
Here are some questions to ask yourself when diagnosing a problem:
If one computer works and another does not, and you are confident that the same software (Oracle and third-party products) is installed, on each computer, swap out the network cables, if they are close enough, to see if the problem moves. If it does move, it indicates that the problem has something to do with the client/server connection and is not local to the PC.
Sniffers and LAN analyzers are useful for intermittent failing connections or detecting time-outs and re-sent packets. You can also see what side of the conversation is waiting for a response.
Oracle Net Services provide detailed information about the source and context of problems as they arise. This information is generated and stored in log and trace files. The process of logging and tracing error information will help you to diagnose and resolve network problems.
All errors encountered in Oracle Net Services are appended to a log file for evaluation by a network or database administrator. The log file provides additional information for an administrator when the error message on the screen is inadequate to understand the failure. The log file, by way of the error stack, shows the state of the software at various layers.
To ensure that all errors are recorded, logging cannot be disabled on clients or Names Servers. Furthermore, only an administrator may replace or erase log files. The log file for the listener also includes Audit Trail information about every client connection request, as well as most listener control commands.
This section contains these topics:
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. Figure 17-1 depicts the relationship among error stack components and Oracle Net.
The error stack components in Figure 17-1 are described in Table 17-2.
As an example, suppose that a user of a client application tries to establish a connection with a database server using Oracle Net and TCP/IP, and the user enters:
sqlplus scott/tiger@hrserver.com
The following error displays:
ORA-12203: TNS:Unable to connect to destination
This message indicates that the connection to the server failed because the database could not be contacted. Although the application displays only a one-line error message, an error stack that is much more informative is recorded in the log file by the network layer.
On the client side, the sqlnet.log file (Figure 17-2) contains an error stack corresponding to the ORA-12203 error.
***********************************************************
Fatal OSN connect error 12203, connecting to: (DESCRIPTION=(CONNECT_DATA=(SID=trace)(CID=(PROGRAM=) (HOST=lala)(USER=sviavant)))(ADDRESS_LIST=(ADDRESS= (PROTOCOL=ipc)(KEY=trace))(ADDRESS=(PROTOCOL=tcp) (HOST=lala)(PORT=1521)))) VERSION INFORMATION: TNS for SunOS: Oracle Bequeath NT Protocol Adapter for SunOS: Unix Domain Socket IPC NT Protocol Adaptor for SunOS: TCP/IP NT Protocol Adapter for SunOS: Tracing to file: /home/sviavant/trace_admin.trc Tns error struct: nr err code: 12203 TNS-12203: TNS:unable to connect to destination ns main err code: 12541 TNS-12541: TNS:no listener ns secondary err code: 12560 nt main err code: 511 TNS-00511: No listener nt secondary err code: 61 nt OS err code: 0
Each Oracle Net Services component produces its own log file. Table 17-3 provides the default log file names and lists the components that generate the log files.
| Log File | Component |
|---|---|
|
|
Listener |
|
|
Oracle Names Server |
|
|
Client or Database Server |
|
|
Oracle Connection Manager CMADMIN process |
|
|
Oracle Connection Manager CMGW process |
Parameters that control logging, including the type and amount of information logged, as well as the location where the files are stored, are set in the configuration file of each network component as described in Table 17-4.
| Network Component | Configuration File |
|---|---|
|
Oracle Connection Manager Processes |
|
|
Listener |
|
|
Oracle Names Server |
|
|
Client |
|
|
Database Server |
|
This section contains these topics:
| See Also:
Oracle9i Net Services Reference Guide for more information about these parameters |
Table 17-5 describes the log parameters settings that can be set in the sqlnet.ora file.
Table 17-6 describes the log parameters settings that can be set in the listener.ora file.
Table 17-7 describes the log parameters settings that can be set in the names.ora file.
Table 17-8 describes the log parameters settings that can be set in the cman.ora file.
Logging parameters for the sqlnet.ora file, listener.ora files and names.ora file can be set with the Oracle Net Manager. The cman.ora file logging parameters must be set manually.
To set logging parameters:
| Log File | Set logging parameters here... |
|---|---|
|
|
|
|
|
|
|
|
Logging can be set during runtime of control utilities. Note that setting logging with a control utility will not set parameters in the *.ORA files; the setting is only valid for the session of the control utility:
SET LOG_FILE and SET LOG_DIRECTORY commands from the Listener Control utility.SET LOG_LEVEL command from the Oracle Connection Manager control utility.SET LOG_FILE_NAME command from the Oracle Names Control utility, or set logging settings through Oracle Net Manager.
To set tracing for an Oracle Names server with Oracle Net Manager:
To use a log file to diagnose a network error:
This section describes what is recorded in the listener log file, including:
The listener log file contains audit trail information that enables you to gather and analyze network usage statistics, as well as information indicating the following:
RELOAD, START, STOP, STATUS, or SERVICES command issued by the Listener Control utilityYou can use Audit Trail information to view trends and user activity by first storing it in a table and then collating it into a report format. To import the data into a table, use an import utility such as SQL*Loader.
The audit trail formats text into the following fields:
Timestamp * Connect Data [* Protocol Info] * Event [* SID | Service] * Return Code
Properties of the audit trail are as follows:
*).See Also:
|
The following output shows a log file excerpt with RELOAD command request.
14-JUL-2002 00:29:54 * (connect_data=(cid=(program=)(host=sales-server)(user=jdoe))(command=stop) (arguments=64)(service=listener)(version=135290880)) * stop * 0
The following output shows a log file excerpt with a successful connection request.
14-JUL-2002 15:28:58 * (connect_data=(service_name=sales.us.acme.com)(cid=(program=)(host=sales-server) (user=jdoe))) * (address=(protocol=tcp)(host=10.10.150.35)(port=41349)) * establish * sales.us.acme.com * 0
The following output shows a log file excerpt with a successful execution of the STATUS command by host sales-server, followed by an unsuccessful connection attempt by a client with an IP address of 10.10.150.35. This connection attempt resulted in an ORA-12525: TNS:listener has not received client's request in time allowed error message, which occurs when a client fails to complete its connect request in the time specified by the INBOUND_CONNECT_TIMEOUT_listener_name parameter in the listener.ora file. This client may be attempting a denial-of-service attack on the listener.
03-JUL-2002 16:41:57 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=sales-server)(USER=jdoe))(COMMAND=status) (ARGUMENTS=64)(SERVICE=LISTENER)(VERSION=153092352)) * status * 0 03-JUL-2002 16:42:35 * <unknown connect data> * (ADDRESS=(PROTOCOL=tcp)(HOST=10.10.150.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
The listener records service registration events. During service registration, the PMON process provides the listener with information about the following:
The service registration-related events listed in Table 17-9 are recorded in the listener.log file:
The service registration events are formatted into the following fields:
Timestamp * Event * Instance Name * Return Code
Properties of service registration fields are as follows:
*).See Also:
|
The following example shows a log file with service registration events. Notice how the listener is able to receive a client request after a successful service_register event, but is unable to receive client requests after a service_died event.
------------------------------- 14-JUL-2002 15:28:43 * service_register * sales * 0 14-JUL-2002 15:28:43 * service_register * sales * 0 14-JUL-2002 15:28:58 * (connect_data=(service_name=sales.us.acme.com)(cid=(program=)(host=sales-server) (user=jdoe))) * (address=(protocol=tcp)(host=10.10.150.35)(port=41349)) * establish * sales.us.acme.com * 0 14-JUL-2002 15:38:44 * service_update * sales * 0 14-JUL-2002 15:38:44 * service_update * sales * 0 14-JUL-2002 15:48:45 * service_update * sales * 0 14-JUL-2002 15:48:45 * service_update * sales * 0 14-JUL-2002 15:50:57 * (connect_data=(service_ name=sales.us.acme.com)(cid=(program=)(host=sales-server)(u ser=jdoe))) * (address=(protocol=tcp)(host=10.10.150.35)(port=41365)) * establish * sales.us.acme.com * 0 14-JUL-2002 15:51:26 * service_died * sales * 12537 14-JUL-2002 15:51:26 * service_died * sales * 12537 14-JUL-2002 15:52:06 * (connect_data=(service_ name=sales.us.acme.com)(cid=(program=)(host=sales-server)(u ser=jdoe))) * (address=(protocol=tcp)(host=10.10.150.35)(port=41406)) * establish * sales.us.acme.com * 12514 TNS-12514: TNS:listener could not resolve SERVICE_NAME given in connect descriptor --------------------------------
The listener records direct hand-off events to dispatchers. These events are formatted into the following fields:
Timestamp * Presentation * Handoff * Error Code
Properties of direct hand-off fields are as follows:
*).| See Also:
"Resolving the Most Common Error Messages for Oracle Net Services" for the most common Oracle Net errors or Oracle9i Database Error Messages for a complete listing of error messages |
A direct hand-off event in the log file is shown in the following example.
21-JUL-2002 10:54:55 * oracle.aurora.net.SALESHttp2 * handoff * 0
Oracle Connection Manager generates two types of log files: one for its CMGW gateway process (cman_pid.log) and one for its CMADMIN administrative process (cmadm_pid.log).
Figure 17-3 and Figure 17-4 show examples of the log files.
(TIMESTAMP=20-JUL-2002 18:03:10)(EVENT=10)(VERSION=8.1.6.0.0) (TIMESTAMP=20-JUL-2002 18:03:10)(EVENT=36)(rule_list= (rule=(src=spcstn)(dst=x)(srv=x)(act=accept))) (TIMESTAMP=20-JUL-2002 18:03:10)(EVENT=32)(PARAMETER_LIST=(MAXIMUM_ RELAYS=1024)(RELAY_STATISTICS=no)(AUTHENTICATION_LEVEL=0)(LOG_LEVEL=1)(SHOW_TNS_ INFO=no)(ANSWER_TIMEOUT=0)(MAXIMUM_CONNECT_DATA=1024)(USE_ASYNC_ CALL=yes)(TRACING=no)(TRACE_DIRECTORY=default)(MAX_FREELIST_BUFFERS=0)) (TIMESTAMP=20-JUL-2002 18:03:10)(EVENT=34)(ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1610)(QUEUESIZE=32))) (TIMESTAMP=20-JUL-2002 18:03:12)(EVENT=38)(COMMAND=2) (TIMESTAMP=20-JUL-2002 18:03:27)(EVENT=26)(RLYNO=0)(SRC=(ADDRESS=(PROTOCOL=tcp)(HOST=spcstn.us.acme.c om)(PORT=34758)))(DST=(ADDRESS=(PROTOCOL=tcp)(HOST=10.10.150.35)(PORT=1581))) (TIMESTAMP=20-JUL-2002 18:03:43)(EVENT=28)(RLYNO=0)(SINCE=20-JUL-2002 18:03:27)(STATISTICS=(IN=(BYTES=0)(PACKETS=0)(DCDS=0)(OUT=(BYTES=0)(PACKETS=0)(D CDS=0)))
(TIMESTAMP=20-JUL-2002 18:03:09)(EVENT=Sent Admin Status to UI) (TIMESTAMP=20-JUL-2002 18:03:10)(EVENT=CMan Registration)
| See Also:
"Analyzing Listener Log Files" on page 17-26 |
The cman_pid.log on UNIX and cmanpid.log on Windows NT reports events using event code numbers. The event code reported depends upon the log level set with the LOG_LEVEL parameter in the cman.ora file or with the Oracle Connection Manager Control utility command SET LOG_LEVEL. Table 17-10 explains what each of these event codes represents.
| Code | Description |
|---|---|
|
10 |
Gateway is starting up |
|
12 |
Gateway is shutting down |
|
14 |
Listening on protocol addresses |
|
18 |
See Also: "Reasons for Event Code 18" |
|
20 |
See Also: "Reasons for Event Code 20" |
|
26 |
Relay is now open |
|
28 |
Relay is now closed |
|
30 |
Statistics report |
|
32 |
< |
|
34 |
< |
|
36 |
< |
|
38 |
Oracle Connection Manager Control utility command |
|
40 |
Oracle Connection Manager Control utility command refused because the gateway is busy |
|
42 |
Dead connection detected |
|
44 |
Relay has timed out |
|
11 |
Bad < |
|
13 |
Bad < |
|
15 |
Bad < |
|
23 |