Oracle® Database Net Services Administrator's Guide 11g Release 1 (11.1) Part Number B28316-01 |
|
|
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 Net8 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:
Oracle software
Operating system layer
Other network layers
Testing the various network layers progressively should, in most cases, uncover any problem.
This section includes the following topics:
In an effort to reduce both downtime and interruptions in business when database problems occur, Oracle has implemented a standardized diagnostic method employed across all Oracle products.
Part of this method consolidates Oracle Net diagnostics and tracing information into a standardized, readable format. This information is stored in a single hierarchical repository. Oracle Net diagnostics data consists of tracing and logging information produced by Oracle clients, application servers, and the database server.
The automatic diagnostic repository (ADR) is a system-wide tracing and logging central repository. The repository is a file-based hierarchical datastore for depositing diagnostic information, including network tracing and logging information.
The ADR Home is the unit of the ADR directory that is assigned to an instance of an Oracle product. Each database instance will have its own ADR Home. Similarly, each listener instance will have its own ADR Home.
The ADR_BASE
is the physical location in which one or more ADR Homes are placed. Conceptually, it is the root directory of ADR.
See Also:
Oracle Database Administrator's Guide for more information about ADRNon-ADR (meaning that the DIAG_ADR_ENABLED
parameter is set to OFF
) diagnostic and tracing methods are still current and applicable but the parameters are ignored if ADR is enabled.
Diagnostic parameters are found in the three configuration files: sqlnet.ora
, listener.ora
, and cman.ora
.
See Also:
Oracle Database Net Services Reference for descriptions of the following diagnostic parametersTable 16-1 compares usage of various diagnostic parameters found in the sqlnet.ora
file used in both non-ADR and ADR-based diagnostics.
Table 16-1 sqlnet.ora File Diagnostic Parameter Comparison
Parameter | Non-ADRDIAG_ADR_ENABLED=OFF | ADRDIAG_ADR_ENABLED=ON |
---|---|---|
ADR_BASEFoot 1 |
No |
Yes |
TRACE_LEVEL_CLIENTFoot 2 |
Yes |
Yes |
TRACE_LEVEL_SERVERFootref 2 |
Yes |
Yes |
TRACE_DIRECTORY_CLIENTFoot 3 |
Yes |
No |
TRACE_FILE_CLIENTFootref 3 |
Yes |
No |
TRACE_UNIQUE_CLIENTFootref 3 |
Yes |
No |
LOG_DIRECTORY_CLIENTFootref 3 |
Yes |
No |
LOG_FILE_CLIENTFootref 3 |
Yes |
No |
LOG_DIRECTORY_SERVERFootref 3 |
Yes |
No |
TRACE_DIRECTORY_SERVERFootref 3 |
Yes |
No |
TRACE_FILE_SERVERFootref 3 |
Yes |
No |
Footnote 1 ADR only parameter. This parameter is not used for non-ADR-based tracing/logging.
Footnote 2 These parameters are functionally equivalent for both non-ADR and ADR-based tracing and logging.
Footnote 3 If DIAG_ADR_ENABLED
is set to ON
, this parameter is ignored. The trace and log files are created in the location defined by ADR_BASE
(See Oracle Database Administrator's Guide for description of ADR directory tree and log/trace file naming conventions).
Table 16-2 compares usage of various diagnostic parameters found in the listener.ora
file used in both non-ADR and ADR-based diagnostics.
Table 16-2 listener.ora File Diagnostic Parameter Comparison
Parameter | Non-ADRDIAG_ADR_ENABLED=OFF | ADRDIAG_ADR_ENABLED=ON |
---|---|---|
ADR_BASE_listener_nameFoot 1 |
No |
Yes |
LOGGING_listener_nameFootref 2 |
Yes |
Yes |
TRACE_LEVEL_listener_nameFoot 2 |
Yes |
Yes |
TRACE_TIMESTAMP_listener_nameFootref 2 |
Yes |
Yes |
LOG_DIRECTORY_CLIENT_listener_nameFootref 3 |
Yes |
No |
LOG_FILE_CLIENT_listener_nameFootref 3 |
Yes |
No |
TRACE_DIRECTORY_CLIENT_listener_nameFoot 3 |
Yes |
No |
TRACE_FILELEN_listener_nameFootref 3 |
Yes |
No |
TRACE_FILENO_listener_nameFootref 3 |
Yes |
No |
Footnote 1 ADR only parameter. This parameter is not used for non-ADR-based tracing/logging.
Footnote 2 These parameters are functionally equivalent for both non-ADR and ADR-based tracing and logging.
Footnote 3 If DIAG_ADR_ENABLED_
listener_name
is set to ON
, this parameter is ignored. The trace and log files are created in the location defined by ADR_BASE_
listener_name
(See Oracle Database Administrator's Guide for description of ADR directory tree and log/trace file naming conventions).
Table 16-3 compares usage of various diagnostic parameters found in the cman.ora
file used in both non-ADR and ADR-based diagnostics.
Table 16-3 cman.ora File Diagnostic Parameter Comparison
Parameter | Non-ADRDIAG_ADR_ENABLED=OFF | ADRDIAG_ADR_ENABLED=ON |
---|---|---|
ADR_BASEFoot 1 |
No |
Yes |
LOG_LEVELFoot 2 |
Yes |
Yes |
TRACE_LEVELFootref 2 |
Yes |
Yes |
TRACE_TIMESTAMPFootref 2 |
Yes |
Yes |
LOG_DIRECTORYFoot 3 |
Yes |
No |
TRACE_DIRECTORYFootref 3 |
Yes |
No |
TRACE_FILELENFootref 3 |
Yes |
No |
TRACE_FILENOFootref 3 |
Yes |
No |
Footnote 1 ADR only parameter. This parameter is not used for non-ADR-based tracing/logging.
Footnote 2 These parameters are functionally equivalent for both non-ADR and ADR-based tracing and logging.
Footnote 3 If DIAG_ADR_ENABLED
is set to ON
, this parameter is ignored. The trace and log files are created in the location defined by ADR_BASE
(See Oracle Database Administrator's Guide for description of ADR directory tree and log/trace file naming conventions).
Trace Assistant
Trace Assistant is a diagnostic tool that completely decodes each packet of Oracle Net tracing data and presents it in a readable and understandable format. Trace Assistant also provides useful statistical information.
ADRCI is a command-line tool that is part of the fault diagnosability infrastructure introduced in Oracle Database 11g. ADRCI enables you to:
View diagnostic data within ADR
Package incident and problem information into a zip file for transmission to Oracle Support
Diagnostic data includes incident and problem descriptions, trace files, dumps, health monitor reports, alert log entries, and more.
ADRCI has a rich command set, and can be used in interactive mode or within scripts. In addition, ADRCI can execute scripts of ADRCI commands in the same way that SQL*Plus executes scripts of SQL and PL/SQL commands.
To view trace files using ADRCI, enter ADRCI
at a command prompt. Following are common commands used for Oracle Net trace diagnosis:
Client Side
adrci>> SHOW BASE -product client adrci>> SET BASE -product client adrci>> SHOW TRACEFILE adrci>> SHOW TRACE trace_file.trc
In the preceding command, SHOW BASE -product client
displays the value of ADR_BASE
for the client. Use that value for client
in the SET BASE
command.
Server Side
adrci>> SHOW BASE
adrci>> SHOW TRACEFILE
adrci>> SHOW TRACE trace_file.trc
In the preceding command, BASE
is defined as $ORACLE_HOME/log
.
Other ADRCI command options are available for a more targeted Oracle Net trace file analysis. Type HELP
at the adrci>>
prompt for in-line help documentation.
See Also:
Oracle Database Utilities for more information about ADRCIAnswer the following questions:
Is any other system (workstation/server) able to connect to the server using Net8?
Has the server, database, or listener configuration remained the same for some time?
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 Net8 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:
Ensure that the listener.ora
, tnsnames.ora
, and sqlnet.ora
files exist in the correct locations, as described in "Localized Configuration File Support".
Follow the instructions in "Testing Configuration on the Database Server" to perform a loopback test.
If the loopback test continues to fail, continue to the next step.
If the loopback test passes, skip to "Client Diagnostics".
Contact Oracle Worldwide Support.
See Also:
Oracle Call Interface Programmer's Guide for the location of the ADR diagnostic filesAt this point, you know the server-side listener works properly, because you could verify at least one of the following statements:
The database server passed a loopback test, showing that the connection worked.
Other computers connect also using Net8 Services to this same database.
Connections from this workstation worked previous to making changes on this computer, such as the installation of a new product or a modification to the network configuration.
To perform diagnostics on the client:
Check that you have installed the same protocol support as was installed on the database server.
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 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 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 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 RADIUS authentication ENTRUST authentication
Note:
RAW is an internal protocol used by Oracle Net.See Also:
Oracle UNIX operating system-specific Administrator's Reference for further information about theadapters
utilityCheck base connectivity for underlying network transport. Net8 technology depends on the underlying network for a successful connection.
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 |
|
To ensure that both the Net8 foundation layer and the appropriate Oracle protocol support are present, verify that all Net8 Services software for the client has been installed.
Ensure that the client computer has the tnsnames.ora
and the sqlnet.ora
files exist in the correct locations.
See Also:
"Localized Configuration File Support"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.
Test the Net8 foundation layer.
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 ensures that the listener is present on the database server.If the connection still fails:
Use tracing, as described in section "Troubleshooting Network Problems Using Log and Trace Files"
Check the Problem/Solution Database Web site on the Oracle Support web site for a specific diagnostics bulletin on the error received
Contact Oracle Support Services
Due 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-03121: no interface driver connection - function not performed
TNS-12500/ORA-12500: TNS: listener failed to start a dedicated server process
ORA-12514: TNS:listener does not currently know of service requested in connectdescriptor
ORA-12520: TNS:listener could not find available handler for requested type of server
ORA-12521: TNS:listener could not resolve INSTANCE_NAME given in connect descriptor
ORA-12525: TNS:listener has not received client's request in time allowed
See Also:
Oracle Database Error Messages for a complete listing of error messagesT:
X:
P:
The username and password were specified from a client computer that had no local Oracle Database installed. Specify a connect string.
tnsnames.ora
configuration file.Verify that a tnsnames.ora
file exists.
See Also:
"Localized Configuration File Support" for configuration file location informationVerify that there are not multiple copies of the tnsnames.ora
file.
In the tnsnames.ora
file, verify that the net service name specified in your connect string is mapped to a connect descriptor.
Verify that there are no duplicate copies of the sqlnet.ora
file.
If you are using domain names, verify that your 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.
If you are not using domain names, and this parameter exists, delete it or disable it by commenting it out.
If you are connecting from a login dialog box, verify that you are not placing an "@" symbol before your connect net service name.
Activate client tracing and repeat the operation.
Verify that the database service or net service name entry exists in the directory that this computer was configured to use.
See Also:
Oracle Internet Directory Administrator's Guide for directory setup instructionsVerify that the sqlnet.ora
file includes the following entry:
NAMES.DIRECTORY_PATH=(ldap, other_naming_methods)
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" further information about setting theSQLNET.INBOUND_CONNECT_TIMEOUT
parameterTurn on tracing to determine where clients are timing out.
Reconfigure the SQLNET.INBOUND_CONNECT_TIMEOUT
parameter in sqlnet.ora
to a larger value.
If you suspect a malicious client, then perform these steps:
Locate the IP address of the client in the 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 10.1.0.2.0 Oracle Bequeath NT Protocol Adapter for Solaris: Version 10.1.0.2.0 TCP/IP NT Protocol Adapter for Solaris: Version 10.1.0.2.0 Time: 03-JUL-2002 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=10.10.150.35)(PORT=52996))
Beware that an IP address can be forged.
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.
Restrict access to the client. For example, you can configure parameters for access rights in the sqlnet.ora
file.
See Also:
"Configuring Database Access Control"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 Windows service is not started
In some cases, these errors can be caused by the same conditions which cause TNS-12549/ORA-12549, TNS-00519, TNS-12540/ORA-12540, TNS-00510, and TNS-12560/ORA-12560 errors.
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.
Wait a moment and try to connect a second time.
Check which services are currently known by the listener by executing the Listener Control utility STATUS
or SERVICES
command.
Check that the SERVICE_NAME
parameter in the connect descriptor specifies a service name known by the listener.
Check for an event in the listener.log
file.
See Also:
"Analyzing Listener Log Files"SERVICE_NAME
/INSTANCE_NAME
, or the database instance is not registered with the listener.If (
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.
See Also:
"Monitoring Services of a Listener"If 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
.
Ensure that the database instance is running. If the instance not running, start it so that it can register with the listener.
INSTANCE_NAME
in the connect descriptor is incorrect, or the database instance is not registered with the listener.Check to make sure the service name specified in the connect descriptor is correct.
Ensure the database instance is running. If the instance not running, 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"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 theINBOUND_CONNECT_TIMEOUT_
listener_name
parameterINBOUND_CONNECT_TIMEOUT_
listener_name
parameter in listener.ora
to a larger value.
If you suspect a malicious client, then perform these steps:
Locate the IP address of the client in 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.
Restrict access to the client. For example, you can configure parameters for access rights in the sqlnet.ora
file.
See Also:
"Configuring Database Access Control"ADDRESS
section of the designated connect descriptor are incorrect.See Also:
Oracle Database Net Services Reference for correct protocol syntaxNumber of open connection that Oracle Net can process simultaneously
Number of memory buffers which 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/ORA-12500 error is also returned. In some cases, these errors can be caused by the same conditions which cause TNS-12549/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.
Ensure that the supplied destination address matches one of the addresses used by the listener.Verify that this is not a version compatibility problem.
Possible limits include:
The maximum number of processes allowed for a single user
The operating system is running low on paging space
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.
In some cases, these errors will be caused by the same conditions which cause TNS-00510, TNS-00519, TNS-12540/ORA-12540, TNS-12549/ORA-12549 errors.
Directory naming issues associated with connectivity errors such as ORA-12154
, ORA-12543
, or ORA-12541
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 -c net_service_name/database_service -b base_DN -f ldif_file
Table 16-4 lists ldifwrite
tool arguments and descriptions for each.
Table 16-4 ldifwrite Arguments
Argument | Description |
---|---|
|
Specify the net service name or database service name that will connect you to the directory server. |
|
Specify the base of the subtree to be written out in LDIF format. |
|
Specify the input file name. |
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
Here are some tips you may find helpful when you are having difficulty diagnosing network problems:
Use the node or network address during configuration instead of the name of the server computer
This eliminates any internal lookup problems and make the connection slightly faster.
If you are using TCP/IP addresses, use the IP address rather than host name
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
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.
Check what is between you and the server
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.
Verify whether or not there is a timing issue
Timing issues are associated with an ORA-12535
error in the client log files.
To resolve this, try speeding up the connection by using exact addresses instead of names and increase the INBOUND_CONNECT_TIMEOUT_
listener_name
parameter in the listener.ora
file. The default value for this parameter is 10 seconds.
Determine which Oracle applications are failing
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:
Do all computers have a problem, or is it just one?
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.
What kind of links exist between the client and the server, for example, X.25, ISDN, Token Ring, or leased line?
Sniffers and LAN analyzers are useful for intermittent failing connections or detecting time outs and resent packets. You can also see what side of the conversation is waiting for a response.
This section offers some solutions to the TNS-12154 error. The TNS-12154 error is encountered when SQL*Net cannot find the alias specified for a connection in the tnsnames.ora
file or other naming adapter.
Before attempting to resolve the problem, it may be helpful to have a printout or view of both the tnsnames.ora
file and the sqlnet.ora
file. Looking at these files at the same time is helpful since references will be made to both.
This section includes the following topics:
The TNS-12154 error appears when SQL*Net cannot find the alias specified for a connection in the tnsnames.ora
file or other naming adapter.
Before attempting to resolve this problem, it is helpful to print out or view both the tnsnames.ora
file and the sqlnet.ora
file. Looking at these files at the same time is helpful because references will be made to both.
The tnsnames.ora
and sqlnet.ora
files are located in the default network administration directory on the client system.
Be sure that the tnsnames.ora
file and the sqlnet.ora
file resemble the following examples.
Example 16-1 tnsnames.ora Sample
DEV1.WORLD = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (Host = 145.45.78.56) (Port = 1521) ) ) (CONNECT_DATA = (SID = ORCL) ) )
Example 16-2 sqlnet.ora Sample
TRACE_LEVEL_CLIENT = OFF SQLNET.AUTHENTICATION_SERVICES = (NONE) NAMES.DIRECTORY_PATH = (TNSNAMES) AUTOMATIC_IPC = OFF
To begin the diagnostic process, determine which section of this document applies to the problem. In the sample files shown in Example 16-1 and Example 16-2, the alias in Example 16-1 is DEV1.WORLD
while the NAMES.DEFAULT_DOMAIN=world
parameter does not exist in Example 16-2.
In this case, add the NAMES.DEFAULT_DOMAIN=world
parameter anywhere in the sqlnet.ora
file. Save the file, and try the connection again.
If the TNS-12154 error still persists, determine whether the files were transferred from the client to the server and check the configuration files to ensure that CTRL-M (^M
) or CTRL-R (^R
) characters were not inserted at the ends of any lines. Remove any such characters you may find.
If the characters do not exist, check to see whether the NAMES.DIRECTORY_PATH
parameter exists in the sqlnet.ora
file and make sure the value in parenthesis is TNSNAMES
, as follows:
NAMES.DIRECTORY_PATH=(TNSNAMES) NAMES.DIRECTORY_PATH=(TNSNAMES, HOSTNAME)
This parameter is not necessary but if it exists in the sqlnet.ora
file and appears as in the preceding example, the configuration files are most likely technically accurate.
At the UNIX prompt, echo the TNS_ADMIN
environment variable, as follows:
% echo $TNS_ADMIN
If nothing is returned, set the TNS_ADMIN
environment variable to explicitly point to the location of the tnsnames.ora
file.
In C shell:
% setenv TNS_ADMIN full_path_to_tnsnames.ora_file
In K shell:
% TNS_ADMIN=full_path_to_tnsnames.ora_file; export TNS_ADMIN
Try the connection again.
If the error persists, add the AUTOMATIC_IPC=OFF
parameter to the sqlnet.ora
file. If AUTOMATIC_IPC
is already set to ON
, change the value to OFF
. Try the connection again.
If the error persists, check the permissions of the tnsnames.ora
and sqlnet.ora
files and parent directories—usually .ora
files are either -rwxrwxrwx
or -rwxrwx---
. Change the permissions of the configuration files to 777
to set the permissions to fully open and try the connection again.
Note:
Setting permissions to777
enables anyone on the system to access the configuration files. Do this only as a temporary test and reset the permissions when finished.If the error persists, redo the configuration as follows:
Set the TNS_ADMIN
environment variable to /tmp
.
Go to the /tmp
directory and create a new tnsnames.ora
file using a text editor.
Copy the sample tnsnames.ora
file from Example 16-1 into the text editor and save the new tnsnames.ora
file.
Exit the text editor and at the command prompt, type:
% sqlplus scott/tiger@dev1.world
This should connect or progress to the next logical error.
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.
The error stack components are described in Table 16-5.
Table 16-5 Error Stack Components
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-12543: 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 (Example 16-3) contains an error stack corresponding to the ORA-12543
error.
Example 16-3 sqlnet.log File
***********************************************************
Fatal OSN connect error 12543, 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: TNS-12543: 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 16-6 provides the default log file names and lists the components that generate the log files.
Table 16-6 Log Files
Log File | Component |
---|---|
Listener |
|
Client or Database Server |
|
Oracle Connection Manager listener |
|
|
Oracle Connection Manager CMGW (Connection Manager gateway) process |
|
Oracle Connection Manager CMADMIN (Connection Manager Administration) process |
instance-name_alert.log |
Oracle Connection Manager alert log |
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 16-7.
Table 16-7 Location of Log Parameters
Network Component | Configuration File |
---|---|
Oracle Connection Manager Processes |
|
Listener |
|
Client |
|
Database Server |
|
This section contains these topics:
Setting Logging Parameters in Configuration Files
See Also:
Oracle Database Net Services Reference for more information about these parametersTable 16-8 describes the log parameters settings that can be set in the sqlnet.ora
file.
Table 16-8 sqlnet.ora Log Parameters
Table 16-9 describes the log parameters settings that can be set in the listener.ora
file.
Table 16-9 listener.ora Log Parameters
Table 16-10 describes the log parameters settings that can be set in the cman.ora
file.
Table 16-10 cman.ora Log Parameters
You configure logging parameters for the sqlnet.ora
file with Oracle Net Manager and listener.ora
file with either Oracle Enterprise Manager or Oracle Net Manager.
You must manually configure cman.ora
file logging parameters.
See Also:
Oracle Database Net Services ReferenceTo set logging parameters with Oracle Enterprise Manager and Oracle Net Manager, refer to Table 16-11.
Table 16-11 Setting Logging Parameters in Configuration Files
Log File | Tool | Set Logging Parameters Here... |
---|---|---|
|
Oracle Net Manager |
|
|
Oracle Enterprise Manager |
|
|
Oracle Net |
|
You can set logging during control utility runtime. Setting logging 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 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.
See Also:
Oracle Database Net Services ReferenceTo use a log file to diagnose a network error:
Review the log file for the most recent error number you received from the application. Note that this is almost always the last entry in the log file.
Starting from the bottom of the file, locate the first nonzero entry in the error report. This is usually the actual cause.
If that error does not provide the desired information, review the next error in the stack until you locate the correct error information.
If the cause of the error is still not clear, turn on tracing and repeat the statement that produced the error message.
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:
A client connection request
A RELOAD
, START
, STOP
, STATUS
, or SERVICES
command issued by the Listener Control utility
You 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:
Each field is delimited by an asterisk (*
).
Protocol address information and service name or SID information appear only when a connection is attempted.
A successful connection or command returns a code of zero.
A failure produces a code that maps to an error message.
See Also:
"Resolving the Most Common Error Messages for Oracle Net Services" for information about resolving the most common Oracle Net errors
Oracle Database Error Messages for a complete listing of error messages
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:
Service names for each running instance of the database
Instance names of the database
Service handlers (dispatchers or dedicated servers) available
Dispatcher, instance, and node load information
Dynamic listening endpoints
The service registration-related events listed in Table 16-12 are recorded in the listener.log
file:
Table 16-12 Service Registration Event Log Information
Event | Description |
---|---|
The listener received registration information for an instance. |
|
The listener received updated registration information for a particular instance, such as dispatcher or instance load information. |
|
The listener lost its connection to PMON. All registration information for the instance is discarded. Clients will be unable to connect to the instance until PMON registers it again. |
The service registration events are formatted into the following fields:
Timestamp * Event * Instance Name * Return Code
Properties of service registration fields are as follows:
Each field is delimited by an asterisk (*
).
It is normal for the events to appear multiple times in a row for one instance.
A successful registration returns a code of zero, meaning the client can connect to the instance.
A failure produces a code that maps to an error message.
See Also:
"Resolving the Most Common Error Messages for Oracle Net Services" for the most common Oracle Net errors
Oracle Database Error Messages for a complete listing of error messages
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:
Each field is delimited by an asterisk (*
).
A successful connection or command returns a code of zero.
A failure produces a code that maps to an error message.
See Also:
"Resolving the Most Common Error Messages for Oracle Net Services" for the most common Oracle Net errors or Oracle Database Error Messages for a complete listing of error messagesListener will subscribe to the Oracle Notification Service (ONS) node down
event on startup if ONS configuration file is available. This subscription enables the listener to remove the affected service when it receives node down
event notification from ONS. The listener uses asynchronous subscription for the event notification. The following warning message will be recorded to listener log file on each STATUS command if the subscription has not completed; for example if the ONS daemon is not running on the host.
WARNING: Subscription for node down event still pending
Listener will not be able to receive the ONS event while subscription is pending. Other than that, no other listener functionality is affected.
If the required Oracle Clusterware (CRS in the following log messages) libraries are installed and Oracle Clusterware is started on the host, Oracle Listener will notify Oracle Clusterware about its status upon start and stop. After successful notification, listeners records the event in the log. No message will be recorded if the notification fails.
Listener completed notification to CRS on start Listener completed notification to CRS on stop
Oracle Connection Manager generates four types of log files: one each for its listener, gateway, and CMADMIN
processes and one for alerts. The last 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. See Table 16-6, "Log Files" for file name syntax.
The CMADMIN
and gateway log files are reproduced here. Table 16-13, "CMADMIN and Gateway Log Entries: What They Mean" explains some of the log entries. Each entry consists of a timestamp and an event. You can configure cman.ora
to log events in 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.
This section includes the following examples:
------------------------------- (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:40)(EVENT=Parameter list) (listener_address=(address=(protocol=tcp)(host=usunnae16)(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) (remote_admin=ON) (trace_directory=/home/user/network/admin/log) (trace_level=off) (trace_timestamp=OFF) (trace_filelen=0) (trace_fileno=0) ) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:40)(EVENT=Shared Memory Size) (BYTES=82524)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:40)(EVENT=GMON Attributes validated) (Type=Information)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:40)(EVENT=NS Listen Successful) ((ADDRESS=(PROTOCOL=tcp)(HOST=usunnae16)(PORT=55878)))) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:44)(EVENT=Received command)(CMD=verify password)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:44)(EVENT=Received command) (CMD=version)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:44)(EVENT=Received command) (CMD=show status)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:44)(EVENT=Failed to get procedure id)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:49:12)(EVENT=Received command)(CMD=verify password)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:49:15)(EVENT=Failed to get procedure id)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:49:29)(EVENT=Received command)(CMD=verify password)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:49:46)(EVENT=Failed to get procedure id)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:49:50)(EVENT=Received command)(CMD=verify password)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:49:50)(EVENT=Received command) (CMD=probe monitor)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:49:50)(EVENT=Received command) (CMD=shutdown normal)) -------------------------------
------------------------------- (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:41)(EVENT=NS Initialised)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:41)(EVENT=Memory Allocated) (BYTES=1024)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:41)(EVENT=NCR Initialised)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:41)(EVENT=Connected to Monitor)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:41)(EVENT=State Change from Empty to Init)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:41)(EVENT=Memory Allocated) (BYTES=251904)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:41)(EVENT=Memory Allocated) (BYTES=2048)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:41)(EVENT=CCB Initialised)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:41)(EVENT=Started Listening)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:41)(EVENT=State Change from Init to Ready)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:46:47)(EVENT=Housekeeping)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:06)(EVENT=Ready)(CONN NO=0)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:06)(EVENT=Ready)(CONN NO=0)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:07)(EVENT=Housekeeping)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:12)(EVENT=Housekeeping)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:13)(EVENT=Idle Timeout)(CONN NO=0)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:17)(EVENT=Housekeeping)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:22)(EVENT=Housekeeping)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:25)(EVENT=Ready)(CONN NO=0)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:25)(EVENT=Ready)(CONN NO=0)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:27)(EVENT=Housekeeping)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:30)(EVENT=Idle Timeout)(CONN NO=0)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:32)(EVENT=Housekeeping)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:37)(EVENT=Housekeeping)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:42)(EVENT=Ready)(CONN NO=0)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:42)(EVENT=Ready)(CONN NO=0)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:42)(EVENT=Housekeeping)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:47)(EVENT=Housekeeping)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:52)(EVENT=Housekeeping)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:48:57)(EVENT=Housekeeping)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:49:02)(EVENT=Session Timeout)(CONN NO=0)) (LOG_RECORD=(TIMESTAMP=08-MAY-2003 08:49:02)(EVENT=Housekeeping)) -------------------------------
Table 16-13 CMADMIN and Gateway Log Entries: What They Mean
Event | Description | Log File |
---|---|---|
GMON Attributes validated |
Informational message. The parameters needed for |
|
Failed to get procedure ID |
The |
|
Out of CCB |
|
Gateway |
No connect data |
An unknown client is trying to connect to |
|
Invalid connect data |
An unknown client is trying to connect to |
|
Housekeeping |
Informational message. Internal housekeeping for the gateway process is in order. The gateway process is properly connected to the |
Gateway |
Connected to Monitor |
The gateway has connected to |
Gateway |
State change from Empty to Init |
State change message from the gateway. Once it reaches a ready state, the gateway begins accepting connections from the client. |
Gateway |
State change from Init to Ready |
State change message from the gateway. Once it reaches a ready state, the gateway begins accepting connections from the client. |
Gateway |
Idle Timeout |
The connection was disconnected because it was idle longer than the time specified in |
Gateway |
Session Timeout |
The connection was disconnected because it exceeded the session timeout specified in |
Tracing produces a detailed sequence of statements that describe network events as they are executed. Tracing an operation enables you to obtain more information on the internal operations of the components of Oracle Net Services than is provided in a log file. This information is output to files that can be evaluated to identify the events that led to an error.
Note:
Tracing uses a large amount of disk space and may have a significant impact upon system performance. Therefore, you should enable tracing only when necessary.This section contains topics:
Each Oracle Net Services component produces its own trace file. Table 16-14 provides the default trace file names and lists the components that generate the trace files.
Table 16-14 Trace Files
Trace File | Component |
---|---|
Oracle Connection Manager listener |
|
|
Oracle Connection Manager CMGW (Connection Manager gateway) process |
|
Oracle Connection Manager CMADMIN (Connection Manager Administration) process |
Listener |
|
Client |
|
Database Server |
|
|
Parameters that control tracing, including the type and amount of information trace, as well as the location where the files are stored, are set in the configuration file of each network component as described in Table 16-15.
Table 16-15 Location of Trace Parameters
Component | Configuration File |
---|---|
Oracle Connection Manager Processes |
|
Listener |
|
Client |
|
Database Server |
|
TNSPING Utility |
|
This section contains these topics:
Setting Tracing Parameters in Configuration Files
See Also:
Oracle Database Net Services Reference for more information about these parametersTable 16-16 describes the trace parameters settings that can be set in the sqlnet.ora
file.
Table 16-16 sqlnet.ora Trace Parameters
You can manually add the following TNSPING utility tracing parameters described in Table 16-17 to sqlnet.ora
. The TNSPING utility determines whether or not a service (such as a database or other TNS services) on a Oracle Net network can be successfully reached.
Table 16-17 TNSPING Trace Parameters
Table 16-18 describes the trace parameters settings for the listener that can be set in the listener.ora
file.
Table 16-18 listener.ora Trace Parameters
Table 16-19 describes the trace parameters settings for Oracle Connection Manager that can be set in the cman.ora
file.
Table 16-19 cman.ora Trace Parameters
cman.ora Parameter | Description |
---|---|
TRACE_DIRECTORY |
Establishes the destination directory for trace files. By default, the directory is |
TRACE_FILELEN |
Specifies the size of the trace file in kilobytes (KB). When the size is met, the trace information is written to the next file. The number of files is specified with the |
TRACE_FILENO |
Specifies the number of trace files for tracing. When this parameter is set along with the The trace file names are distinguished from one another by their sequence number. For example, if this parameter is set to 3, the Oracle Connection Manager trace files for the gateway processes would be named In addition, trace events in the trace files are preceded by the sequence number of the file. |
TRACE_LEVEL |
Specifies the trace level for the Oracle Connection Manager instance. This parameter accepts four trace levels:
The Oracle Connection Manager listener, gateway, and CMADMIN processes create trace files on both UNIX and Windows. See Table 16-14, "Trace Files" for file name syntax. |
TRACE_TIMESTAMP |
If the |
You configure tracing parameters for the sqlnet.ora
file with Oracle Net Manager and listener.ora
file with either Oracle Enterprise Manager or Oracle Net Manager.
You must manually configure cman.ora
file tracing parameters.
See Also:
Oracle Database Net Services ReferenceTo set tracing parameters with Oracle Enterprise Manager and Oracle Net Manager, refer to Table 16-20
Table 16-20 Set Tracing Parameters in Configuration Files
Trace File | Tool | Set Logging Parameters Here... |
---|---|---|
|
Oracle Net Manager |
|
|
Oracle Enterprise Manager |
|
|
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 an Oracle Connection Manager, use the SET
TRACE_DIRECTORY
and SET TRACE_LEVEL
, and SET TRACE_TIMESTAMP
commands from the Oracle Connection Manager control utility.
See Also:
Oracle Database Net Services ReferenceThis section includes the following topics:
Trace files can help Oracle Support Services diagnose and troubleshoot network problems.
This section explains how to perform basic analysis of trace files. The topics discussed include:
Oracle Net performs its functions by sending and receiving data packets.By specifying a trace level of support
, you can view the actual contents of the Oracle Net packet in your trace file. The order of the packet types sent and received will help you to determine how your connection was established.
Each line in the trace file begins with a procedure followed by a message. Following each procedure is a line of hexadecimal data representing actual data. The actual data that flows inside the packet is sometimes viewable to the right of the hexadecimal data.
Next is a list of the Oracle Net packet keywords and descriptions of the types of packets they represent:
Keyword | Packet Type |
---|---|
NSPTCN |
Connect |
NSPTAC |
Accept |
NSPTRF |
Refuse |
NSPTRS |
Resend |
NSPTDA |
Data |
NSPCNL |
Control |
NSPTMK |
Marker |
For example, the following line describes a procedure called "nscon
" sending a NSPTCN
packet over the network:
nscon: sending NSPTCN packet
Each packet has a keyword that denotes the packet type. All packet types begin with the prefix "nsp
". It is helpful to remember this when reviewing trace files for specific packet information
Example 16-4 provides typical packet information.
Example 16-4 Packet Information
nscon: entry nscon: doing connect handshake... nscon: sending NSPTCN packet nspsend: entry nspsend: plen=187, type=1 nspsend: 187 bytes to transport nspsend:packet dump nspsend:00 BB 00 00 01 00 00 00 |........| nspsend:01 33 01 2C 0C 01 08 00 |.3.,....| nspsend:7F FF 7F 08 00 00 00 01 |........| nspsend:00 99 00 22 00 00 08 00 |..."....| nspsend:01 01 28 44 45 53 43 52 |..(DESCR| nspsend:49 50 54 49 4F 4E 3D 28 |IPTION=(| nspsend:43 4F 4E 4E 45 43 54 5F |CONNECT_| nspsend:44 41 54 41 3D 28 53 49 |DATA=(SI| nspsend:44 3D 61 70 33 34 37 64 |D=ap347d| nspsend:62 31 29 28 43 49 44 3D |b1)(CID=| nspsend:28 50 52 4F 47 52 41 4D |(PROGRAM| nspsend:3D 29 28 48 4F 53 54 3D |=)(HOST=| nspsend:61 70 32 30 37 73 75 6E |ap207sun| nspsend:29 28 55 53 45 52 3D 6D |)(USER=m| nspsend:77 61 72 72 65 6E 29 29 |warren))| nspsend:29 28 41 44 44 52 45 53 |)(ADDRES| nspsend:53 5F 4C 49 53 54 3D 28 |S_LIST=(| nspsend:41 44 44 52 45 53 53 3D |ADDRESS=| nspsend:28 50 52 4F 54 4F 43 4F |(PROTOCO| nspsend:4C 3D 74 63 70 29 28 48 |L=tcp)(H| nspsend:4F 53 54 3D 61 70 33 34 |OST=ap34| nspsend:37 73 75 6E 29 28 50 4F |7sun)(PO| nspsend:52 54 3D 31 35 32 31 29 |RT=1521)| nspsend:29 29 29 00 00 00 00 00 |))).....| nspsend: normal exit nscon: exit (0)
When there is a problem a connection, the error code is logged in the trace file. Example 16-5 depicts typical trace file output for a failed SQL*Plus connection to a database server.
Example 16-5 Trace Example
[22-JUL-2002 13:34:07:687] nsprecv: entry [22-JUL-2002 13:34:07:687] nsbal: entry [22-JUL-2002 13:34:07:687] nsbgetfl: entry [22-JUL-2002 13:34:07:687] nsbgetfl: normal exit [22-JUL-2002 13:34:07:687] nsmal: entry [22-JUL-2002 13:34:07:687] nsmal: 44 bytes at 0x132d90 [22-JUL-2002 13:34:07:687] nsmal: normal exit [22-JUL-2002 13:34:07:687] nsbal: normal exit [22-JUL-2002 13:34:07:687] nsprecv: reading from transport... [22-JUL-2002 13:34:07:687] nttrd: entry [22-JUL-2002 13:35:09:625] nttrd: exit [22-JUL-2002 13:35:09:625] ntt2err: entry [22-JUL-2002 13:35:09:625] ntt2err: Read unexpected EOF ERROR on 10 [22-JUL-2002 13:35:09:625] ntt2err: exit [22-JUL-2002 13:35:09:625] nsprecv: transport read error [22-JUL-2002 13:35:09:625] nsprecv: error exit [22-JUL-2002 13:35:09:625] nserror: entry [22-JUL-2002 13:35:09:625] nserror: nsres: id=0, op=68, ns=12537, ns2=12560; nt[0]=507, nt[1]=0, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0 [22-JUL-2002 13:35:09:625] nscon: error exit [22-JUL-2002 13:35:09:625] nsdo: nsctxrnk=0 [22-JUL-2002 13:35:09:625] nsdo: error exit [22-JUL-2002 13:35:09:625] nscall: unexpected response [22-JUL-2002 13:35:09:625] nsclose: entry [22-JUL-2002 13:35:09:625] nstimarmed: entry [22-JUL-2002 13:35:09:625] nstimarmed: no timer allocated [22-JUL-2002 13:35:09:625] nstimarmed: normal exit [22-JUL-2002 13:35:09:625] nsdo: entry [22-JUL-2002 13:35:09:625] nsdo: cid=0, opcode=98, *bl=0, *what=0, uflgs=0x440, cflgs=0x2 [22-JUL-2002 13:35:09:625] nsdo: rank=64, nsctxrnk=0 [22-JUL-2002 13:35:09:625] nsdo: nsctx: state=1, flg=0x4201, mvd=0 [22-JUL-2002 13:35:09:625] nsbfr: entry [22-JUL-2002 13:35:09:625] nsbaddfl: entry [22-JUL-2002 13:35:09:625] nsbaddfl: normal exit [22-JUL-2002 13:35:09:625] nsbfr: normal exit [22-JUL-2002 13:35:09:625] nsbfr: entry [22-JUL-2002 13:35:09:625] nsbaddfl: entry [22-JUL-2002 13:35:09:625] nsbaddfl: normal exit [22-JUL-2002 13:35:09:625] nsbfr: normal exit [22-JUL-2002 13:35:09:625] nsdo: nsctxrnk=0 [22-JUL-2002 13:35:09:625] nsdo: normal exit [22-JUL-2002 13:35:09:625] nsclose: closing transport [22-JUL-2002 13:35:09:625] nttdisc: entry [22-JUL-2002 13:35:09:625] nttdisc: Closed socket 10 [22-JUL-2002 13:35:09:625] nttdisc: exit [22-JUL-2002 13:35:09:625] nsclose: global context check-out (from slot 0) complete [22-JUL-2002 13:35:09:703] nsnadisc: entry [22-JUL-2002 13:35:09:703] nadisc: entry [22-JUL-2002 13:35:09:703] nacomtm: entry [22-JUL-2002 13:35:09:703] nacompd: entry [22-JUL-2002 13:35:09:703] nacompd: exit [22-JUL-2002 13:35:09:703] nacompd: entry [22-JUL-2002 13:35:09:703] nacompd: exit [22-JUL-2002 13:35:09:703] nacomtm: exit [22-JUL-2002 13:35:09:703] nas_dis: entry [22-JUL-2002 13:35:09:703] nas_dis: exit [22-JUL-2002 13:35:09:703] nau_dis: entry [22-JUL-2002 13:35:09:703] nau_dis: exit [22-JUL-2002 13:35:09:703] naeetrm: entry [22-JUL-2002 13:35:09:703] naeetrm: exit [22-JUL-2002 13:35:09:703] naectrm: entry [22-JUL-2002 13:35:09:703] naectrm: exit [22-JUL-2002 13:35:09:703] nagbltrm: entry [22-JUL-2002 13:35:09:703] nau_gtm: entry [22-JUL-2002 13:35:09:703] nau_gtm: exit [22-JUL-2002 13:35:09:703] nagbltrm: exit [22-JUL-2002 13:35:09:703] nadisc: exit [22-JUL-2002 13:35:09:703] nsnadisc: normal exit [22-JUL-2002 13:35:09:703] nsbfr: entry [22-JUL-2002 13:35:09:703] nsbaddfl: entry [22-JUL-2002 13:35:09:703] nsbaddfl: normal exit [22-JUL-2002 13:35:09:703] nsbfr: normal exit [22-JUL-2002 13:35:09:703] nsmfr: entry [22-JUL-2002 13:35:09:703] nsmfr: 2256 bytes at 0x130508 [22-JUL-2002 13:35:09:703] nsmfr: normal exit [22-JUL-2002 13:35:09:703] nsmfr: entry [22-JUL-2002 13:35:09:703] nsmfr: 484 bytes at 0x1398a8 [22-JUL-2002 13:35:09:703] nsmfr: normal exit [22-JUL-2002 13:35:09:703] nsclose: normal exit [22-JUL-2002 13:35:09:703] nscall: connecting... [22-JUL-2002 13:35:09:703] nsclose: entry [22-JUL-2002 13:35:09:703] nsclose: normal exit [22-JUL-2002 13:35:09:703] nladget: entry [22-JUL-2002 13:35:09:734] nladget: exit [22-JUL-2002 13:35:09:734] nsmfr: entry [22-JUL-2002 13:35:09:734] nsmfr: 144 bytes at 0x132cf8 [22-JUL-2002 13:35:09:734] nsmfr: normal exit [22-JUL-2002 13:35:09:734] nsmfr: entry [22-JUL-2002 13:35:09:734] nsmfr: 156 bytes at 0x138e70 [22-JUL-2002 13:35:09:734] nsmfr: normal exit [22-JUL-2002 13:35:09:734] nladtrm: entry [22-JUL-2002 13:35:09:734] nladtrm: exit [22-JUL-2002 13:35:09:734] nscall: error exit [22-JUL-2002 13:35:09:734] nioqper: error from nscall [22-JUL-2002 13:35:09:734] nioqper: ns main err code: 12537 [22-JUL-2002 13:35:09:734] nioqper: ns (2) err code: 12560 [22-JUL-2002 13:35:09:734] nioqper: nt main err code: 507 [22-JUL-2002 13:35:09:734] nioqper: nt (2) err code: 0 [22-JUL-2002 13:35:09:734] nioqper: nt OS err code: 0 [22-JUL-2002 13:35:09:734] niomapnserror: entry [22-JUL-2002 13:35:09:734] niqme: entry [22-JUL-2002 13:35:09:734] niqme: reporting NS-12537 error as ORA-12537 [22-JUL-2002 13:35:09:734] niqme: exit [22-JUL-2002 13:35:09:734] niomapnserror: returning error 12537 [22-JUL-2002 13:35:09:734] niomapnserror: exit [22-JUL-2002 13:35:09:734] niotns: Couldn't connect, returning 12537 [22-JUL-2002 13:35:10:734] niotns: exit [22-JUL-2002 13:35:10:734] nsbfrfl: entry [22-JUL-2002 13:35:10:734] nsbrfr: entry [22-JUL-2002 13:35:10:734] nsbrfr: nsbfs at 0x132d90, data at 0x132dc8. [22-JUL-2002 13:35:10:734] nsbrfr: normal exit [22-JUL-2002 13:35:10:734] nsbrfr: entry [22-JUL-2002 13:35:10:734] nsbrfr: nsbfs at 0x1248d8, data at 0x132210. [22-JUL-2002 13:35:10:734] nsbrfr: normal exit [22-JUL-2002 13:35:10:734] nsbrfr: entry [22-JUL-2002 13:35:10:734] nsbrfr: nsbfs at 0x12d820, data at 0x1319f0. [22-JUL-2002 13:35:10:734] nsbrfr: normal exit [22-JUL-2002 13:35:10:734] nsbfrfl: normal exit [22-JUL-2002 13:35:10:734] nigtrm: Count in the NI global area is now 1 [22-JUL-2002 13:35:10:734] nigtrm: Count in the NL global area is now 1
The most efficient way to evaluate error codes is to find the most recent nserror
entry logged, as the session layer controls the connection. The most important error messages are the ones at the bottom of the file. They are the most recent errors and the source of the problem with the connection.
For information about the specific return codes, use the Oracle UNIX error tool oerr
, by entering the following at any command line:
oerr tns error_number
As an example, consider the following nserror
entry logged in the trace file shown in Example 16-5:
[22-JUL-2002 13:35:09:625] nserror: nsres: id=0, op=68, ns=12537, ns2=12560; nt[0]=507, nt[1]=0, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0
Using oerr
, you can find out more information about return codes 12537 and 507. (Bold denotes user input.)
oerr tns 12537 12537, 00000, "TNS:connection closed" // *Cause: "End of file" condition has been reached; partner has disconnected. // *Action: None needed; this is an information message. oerr tns 507 00507, 00000, "Connection closed" // *Cause: Normal "end of file" condition has been reached; partner has // disconnected. // *Action: None needed; this is an information message.
Oracle Net Services provides a tool called the Trace Assistant to help you understand the information provided in trace files by converting existing lines of trace file text into a more readable paragraph. Note that the Trace Assistant runs against only a level 16
(support
) Oracle Net Services trace file.
Note:
The Trace Assistant can only be used whenDIAG_ADR_ENABLED
is set to off
.This section contains the following topics:
To run the Trace Assistant, enter the following at any command line prompt:
trcasst [options] <filename>
The options are described in Table 16-21.
Table 16-21 Trace Assistant Syntax
Option | Description |
---|---|
|
Displays error information. After the
|
|
If a connection ID exists in the NS connect packet, then the output displays the connection IDs. Connection IDs are displayed as hexadecimal, eight-byte IDs. A generated ID is created by Trace Assistant if the packet is not associated with any connection, that is, the connect packet is overwritten in the trace file. This can occur with cyclic trace files. For each ID, the output lists the following:
Notes:
|
|
Displays the trace for a particular ID from the Note: Only use this option with output from the |
|
Displays the amount and type of information to be output. After the
Note: As output for |
|
Oracle internal use only |
|
Displays the following statistical information:
|
If no options are provided, then the default is -odt -e0 -s
, providing detailed connectivity and TTC events, error level zero (0
), and statistics in the trace file.
Example 16-6 shows how the Trace Assistant converts trace file information into a more readable format.
Example 16-6 Trace File with Error
ntus2err: exit ntuscni: exit ntusconn: exit nserror: entry -<ERROR>- nserror: nsres: id=0, op=65, ns=12541, ns2=12560; nt[0]=511, nt[1]=2, nt[2]=0
Example 16-7 shows how the Trace Assistant converts the trace file information into a more readable format with the -e1
option.
Example 16-7 trcasst -e1 Output
************************************************************************* * Trace Assistant * ************************************************************************* ntus2err: exit ntuscni: exit ntusconn: exit nserror: entry -<ERROR>- nserror: nsres: id=0, op=65, ns=12541, ns2=12560; nt[0]=511, nt[1]=2, nt[2]=0 /////////////////////////////////////////////////////////////// Error found. Error Stack follows: id:0 Operation code:65 NS Error 1:12541 NS Error 2:12560 NT Generic Error:511 Protocol Error:2 OS Error:0 NS & NT Errors Translation 12541, 00000 "TNS:no listener" // *Cause: The connection request could not be completed because the listener // is not running. // *Action: Ensure that the supplied destination address matches one of // the addresses used by the listener - compare the TNSNAMES.ORA entry with // the appropriate LISTENER.ORA file (or TNSNAV.ORA if the connection is to // go by way of an Interchange). Start the listener on the remote machine. / 12560, 00000 "TNS:protocol adapter error" // *Cause: A generic protocol adapter error occurred. // *Action: Check addresses used for proper protocol specification. Before // reporting this error, look at the error stack and check for lower level // transport errors.For further details, turn on tracing and reexecute the // operation. Turn off tracing when the operation is complete. / 00511, 00000 "No listener" // *Cause: The connect request could not be completed because no application // is listening on the address specified, or the application is unable to // service the connect request in a sufficiently timely manner. // *Action: Ensure that the supplied destination address matches one of // the addresses used by the listener - compare the TNSNAMES.ORA entry with // appropriate LISTENER.ORA file (or TNSNAV.ORA if the connection is to go // by way of an Interchange. Start the listener on the remote machine. / /////////////////////////////////////////////////////////////// ************************************************************************* * Trace Assistant has completed * *************************************************************************
However, other errors may also exist within the trace file that were not logged from the nserror
function.
Trace Assistant also enables you to view data packets from both the Oracle Net and TTC communication layers. Trace Assistant offers you two options to view these packets:
Summary connectivity (using option -oc
)
Detailed connectivity (using option -od
)
Example 16-8 shows summary information from the -oc
option. The output shows....
Example 16-8 trcasst -oc Output
************************************************************************* * Trace Assistant * ************************************************************************* ---> Send 198 bytes - Connect packet Connect data length: 140 Connect Data: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=sales.us.acme.com)(CID=(PROGRAM=) (HOST=sales-server)(USER=joe)))) <--- Received 76 bytes - Redirect packet Redirect data length: 66 Redirect Data: (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)) ---> Send 198 bytes - Connect packet Connect data length: 140 Connect Data: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=sales.us.acme.com)(CID=(PROGRAM=) (HOST=sales-server)(USER=joe)))) <--- Received 32 bytes - Accept packet Connect data length: 0 ---> Send 153 bytes - Data packet Native Services negotiation packet <--- Received 127 bytes - Data packet Native Services negotiation packet ---> Send 32 bytes - Data packet <--- Received 140 bytes - Data packet ************************************************************************* * Trace Assistant has completed * *************************************************************************
Note that the packets being sent or received have a prefix of "---> Send
nnn
bytes
" or "<--- Received
nnn
bytes
" showing that this node is sending or receiving a packet of a certain type and with nnn
number of bytes. This prefix enables you to determine if the node is the client or the database server. The connection request is always sent by the client, but received by the database server (or listener).
Example 16-9 shows detailed information from the -od
option. The output shows all of the details sent along with the connect data in negotiating a connection.
Example 16-9 trcasst -od Output
************************************************************************* * Trace Assistant * ************************************************************************* ---> Send 241 bytes - Connect packet Current NS version number is: 311. Lowest NS version number can accommodate is: 300. Global options for the connection: can receive attention no attention processing Don't care Maximum SDU size:8192 Maximum TDU size:32767 NT protocol characteristics: Test for more data Test operation Full duplex I/O Urgent data support Generate SIGURG signal Generate SIGPIPE signal Generate SIGIO signal Handoff connection to another Line turnaround value :0 Connect data length :183 Connect data offset :58 Connect data maximum size :512 Native Services wanted NAU doing O3LOGON - DH key foldedin Native Services wanted NAU doing O3LOGON - DH key foldedin Cross facility item 1: 0 Cross facility item 2: 0 Connection id : Ox000059F70000004C (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=sales.us.acme.com)(SRVR=SHARED)(CID=(PROGRAM=) (HOST=sales-server)(USER=joe)))) <--- Received 76 bytes - Redirect packet Redirect data length: 66 (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)) ---> Send 241 bytes - Connect packet Current NS version number is: 311. Lowest NS version number can accommodate is: 300. Global options for the connection: can receive attention no attention processing Don't care Maximum SDU size:8192 Maximum TDU size:32767 NT protocol characteristics: Test for more data Test operation Full duplex I/O Urgent data support Generate SIGURG signal Generate SIGPIPE signal Generate SIGIO signal Handoff connection to another Line turnaround value :0 Connect data length :183 Connect data offset :58 Connect data maximum size :512 Native Services wanted NAU doing O3LOGON - DH key foldedin Native Services wanted NAU doing O3LOGON - DH key foldedin Cross facility item 1: 0 Cross facility item 2: 0 Connection id : Ox000059F70000007A (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=sales.us.acme.com)(SRVR=SHARED)(CID=(PROGRAM=) (HOST=sales-server)(USER=joe)))) <--- Received 32 bytes - Accept packet Accepted NS version number is: 310. Global options for the connection: no attention processing Don't care Accepted maximum SDU size: 8192 Accepted maximum TDU size: 32767 Connect data length: 0 Native Services wanted NAU doing O3LOGON - DH key foldedin Native Services wanted NAU doing O3LOGON - DH key foldedin ---> Send 153 bytes - Data packet Native Services negotiation packet version#: 150999040 Service data packet #0 for Supervisor has 3 subpackets Subpacket #0: Version #150999040 Subpacket #1: 0000000000000000 Subpacket #2: DEADBEEF0003000000040004000100010002 Service data packet #1 for Authentication has 3 subpackets Subpacket #0: Version #150999040 Subpacket #1: UB2: 57569 Subpacket #2: FCFF Service data packet #2 for Encryption has 2 subpackets Subpacket #0: Version #150999040 Subpacket #1: 000000000000000000 Service data packet #3 for Data Integrity has 2 subpackets Subpacket #0: Version #150999040 Subpacket #1: 000000 <--- Received 127 bytes - Data packet Native Services negotiation packet version#: 135290880 Service data packet #0 for Supervisor has 3 subpackets Subpacket #0: Version #135290880 Subpacket #1: 0000 Subpacket #2: DEADBEEF00030000000200040001 Service data packet #1 for Authentication has 2 subpackets Subpacket #0: Version #135290880 Subpacket #1: FBFF Service data packet #2 for Encryption has 2 subpackets Subpacket #0: Version #135290880 Subpacket #1: UB1: 0 Service data packet #3 for Data Integrity has 2 subpackets Subpacket #0: Version #135290880 Subpacket #1: UB1: 0 .... ---> Send 11 bytes - Marker packet One data byte. Hex character sent over to the server: 2 <--- Received 11 bytes - Marker packet One data byte. Hex character sent over to the server: 2 <--- Received 155 bytes - Data packet ---> Send 25 bytes - Data packet <--- Received 11 bytes - Data packet ---> Send 13 bytes - Data packet <--- Received 11 bytes - Data packet ---> Send 10 bytes - Data packet Data Packet flags: End of file ************************************************************************* * Trace Assistant has completed * *************************************************************************
TTC handles requests such as open cursor, select rows, and update rows that are directed to the database server. All requests are answered by the database server. If you request to logon, a response is returned from the database server that the request was completed.
Summary information for TTC from the -ou
option is different from other displays in that it shows two packets on each line, rather than one. This is done to mirror the request/response pairings process by which TTC operates.
Example 16-10 shows all of the details sent along with the connect data in negotiating a connection.
Example 16-10 trcasst -ou Output
************************************************************************* * Trace Assistant * ************************************************************************* Bytes Bytes Sent Rcvd Send operation(TTIPRO) 32 140 Send operation(TTIDTY) 33 22 Get the session key (OSESSKEY) 229 145 Generic authentication call (OAUTH) 368 1001 Send operation(TTIPFN) 44 144 Send operation(TTIPFN) 36 16 Parse a statement (OSQL) # 1 SELECT USER FROM ... 47 100 Fast upi calls to opial7 (OALL7) # 1 130 111 Fetch row (OFETCH) # 1 21 137 Close cursor (OCLOSE) # 1 17 11 New v8 bundled call (OALL8) # 0 !Keep Parse BEGI... 156 145 Send operation(TTIPFN) 51 16 Parse a statement (OSQL) # 1 SELECT ATTRIBUTE,... 186 100 Fast upi calls to opial7 (OALL7) # 1 246 111 Fetch row (OFETCH) # 1 21 126 Close cursor (OCLOSE) # 1 17 11 Send operation(TTIPFN) 36 16 Parse a statement (OSQL) # 1 SELECT CHAR_VALUE... 208 100 Fast upi calls to opial7 (OALL7) # 1 130 111 Fetch row (OFETCH) # 1 21 126 Close cursor (OCLOSE) # 1 17 11 Send operation(TTIPFN) 36 16 Fast upi calls to opial7 (OALL7) # 1 !Keep Parse BEGI... 183 41 Send operation(TTIRXD) 20 111 Close cursor (OCLOSE) # 1 17 11 New v8 bundled call (OALL8) # 0 Parse Fetch SELE... 165 278 Send operation(TTIPFN) 51 16 Parse a statement (OSQL) # 1 commit 31 100 Execute statement (OEXEC) # 1 number of rows: 1 25 100 Close cursor (OCLOSE) # 1 17 11 Send operation(TTIPFN) 36 16 Fast upi calls to opial7 (OALL7) # 1 !Keep Parse BEGI... 183 41 Send operation(TTIRXD) 60 111 Close cursor (OCLOSE) # 1 17 11 Send operation(TTIPFN) 36 16 Fast upi calls to opial7 (OALL7) # 1 !Keep Parse BEGI... 183 41 Send operation(TTIRXD) 20 111 Close cursor (OCLOSE) # 1 17 11 New v8 bundled call (OALL8) # 0 Parse Fetch sele... 144 383 New v8 bundled call (OALL8) # 1 !Keep Fetch 121 315 Logoff off of Oracle (OLOGOFF) 13 11 ************************************************************************* * Trace Assistant has completed * *************************************************************************
Output is displayed in the following format:
description TTC_message cursor_number SQL_statement bytes_sent bytes_received
On each line of the output, the first item displayed is the actual request made. The second item shows on what cursor that operation has performed. The third item is either a listing of the SQL command or flag that is being answered. The number of bytes sent and received are displayed at the far right. A flag can be one of the following:
!PL/SQL = Not a PL/SQL request COM = Commit IOV = Get I/O Vector DEFN = Define EXEC = Execute FETCH = Fetch CAN = Cancel DESCSEL = Describe select DESCBND = Describe Bind BND = Bind PARSE = Parse EXACT = Exact
Example 16-11 shows detailed SQL information from the -ouq
option.
Example 16-11 trcasst -ouq Output
************************************************************************* * Trace Assistant * ************************************************************************* Bytes Bytes Sent Rcvd Send operation(TTIPRO) 32 140 Send operation(TTIDTY) 33 22 Get the session key (OSESSKEY) 229 145 Generic authentication call (OAUTH) 368 1001 Send operation(TTIPFN) 44 144 Send operation(TTIPFN) 36 16 Parse a statement (OSQL) # 1 47 100 SELECT USER FROM DUAL Fast upi calls to opial7 (OALL7) # 1 130 111 Fetch row (OFETCH) # 1 21 137 Close cursor (OCLOSE) # 1 17 11 New v8 bundled call (OALL8) # 0 !Keep Parse 156 145 BEGIN DBMS_OUTPUT.DISABLE; END; Send operation(TTIPFN) 51 16 Parse a statement (OSQL) # 1 186 100 SELECT ATTRIBUTE,SCOPE,NUMERIC_VALUE,CHAR_VALUE,DA TE_VALUE FROM SYSTEM.PRODUCT_PRIVS WHERE (UPPER('S QL*Plus') LIKE UPPER(PRODUCT)) AND (UPPER(USER) LI KE USERID) Fast upi calls to opial7 (OALL7) # 1 246 111 Fetch row (OFETCH) # 1 21 126 Close cursor (OCLOSE) # 1 17 11 Send operation(TTIPFN) 36 16 Parse a statement (OSQL) # 1 208 100 SELECT CHAR_VALUE FROM SYSTEM.PRODUCT_PRIVS WHERE (UPPER('SQL*Plus') LIKE UPPER(PRODUCT)) AND ((UPPE R(USER) LIKE USERID) OR (USERID = 'PUBLIC')) AND ( UPPER(ATTRIBUTE) = 'ROLES') Fast upi calls to opial7 (OALL7) # 1 130 111 Fetch row (OFETCH) # 1 21 126 Close cursor (OCLOSE) # 1 17 11 Send operation(TTIPFN) 36 16 Fast upi calls to opial7 (OALL7) # 1 !Keep Parse 183 41 BEGIN DBMS_APPLICATION_INFO.SET_MODULE(:1,NULL); E ND; Send operation(TTIRXD) 20 111 Close cursor (OCLOSE) # 1 17 11 New v8 bundled call (OALL8) # 0 Parse Fetch 165 278 SELECT DECODE('A','A','1','2') FROM DUAL Send operation(TTIPFN) 51 16 Parse a statement (OSQL) # 1 31 100 commit Execute statement (OEXEC) # 1 number of rows: 1 25 100 Close cursor (OCLOSE) # 1 17 11 Send operation(TTIPFN) 36 16 Fast upi calls to opial7 (OALL7) # 1 !Keep Parse 183 41 BEGIN DBMS_APPLICATION_INFO.SET_MODULE(:1,NULL); E ND; Send operation(TTIRXD) 60 111 Close cursor (OCLOSE) # 1 17 11 Send operation(TTIPFN) 36 16 Fast upi calls to opial7 (OALL7) # 1 !Keep Parse 183 41 BEGIN DBMS_APPLICATION_INFO.SET_MODULE(:1,NULL); E ND; Send operation(TTIRXD) 20 111 Close cursor (OCLOSE) # 1 17 11 New v8 bundled call (OALL8) # 0 Parse Fetch 144 383 select * from dept New v8 bundled call (OALL8) # 1 !Keep Fetch 121 315 Logoff off of Oracle (OLOGOFF) 13 11 ************************************************************************* * Trace Assistant has completed * *************************************************************************
Example 16-12 shows detailed TTC information from the -ot
option.
Example 16-12 trcasst -ot Output
************************************************************************* * Trace Assistant * ************************************************************************* Set protocol (TTIPRO) Operation 01 (con) Send protocol version=6 Originating platform: SVR4-be-8.1.0 Set protocol (TTIPRO) Operation 01 (con) Receive protocol version=6 Destination platform: SVR4-be-8.1.0 Set datatypes (TTIDTY) Set datatypes (TTIDTY) Start of user function (TTIFUN) (OSESSKEY) Return opi parameter (TTIRPA) Start of user function (TTIFUN) (OAUTH) Return opi parameter (TTIRPA) Start of user function (TTIFUN) session operations 71 (O71SESOPN) (switch session) Return opi parameter (TTIRPA) Start of user function (TTIFUN) Get Oracle version/date string in new format (OVERSION) Return opi parameter (TTIRPA) Oracle Enterprise Edition Release 10.1.0.2.0 With the Partitioning option JServer Release 10.1.0.2.0 Start of user function (TTIFUN) session operations 71 (O71SESOPN) (switch session) Return opi parameter (TTIRPA) Start of user function (TTIFUN) Open a cursor (OOPEN) Return opi parameter (TTIRPA) Cursor #: 1 Start of user function (TTIFUN) Parse a statement (OSQL) Cursor # 1 SELECT USER FROM DUAL ************************************************************************* * Trace Assistant has completed * *************************************************************************
Example 16-13 shows output from the -la
option. The output shows the following information:
Connect IDs received
Socket ID on which this connection has come
Operation
Receive
identifies the trace as a database server trace; Send
identifies the trace as a client trace. In this output, Receive
is the operation.
MULTIPLEX
attribute of the DISPATCHERS
parameter is set to ON
32-bit session ID
Connect data information received
Example 16-13 trcasst -la Output
************************************************************************* * Trace Assistant * ************************************************************************* Connection ID: 00000B270000000B Socket Id: 15 Operation: Receive Multiplex: ON Session Id: 8362785DE4FC0B19E034080020F793E1 Connect Data: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA=(SERVER=shared) (SERVICE_NAME=sales.us.acme.com)(CID=(PROGRAM=)(HOST=sales-server) (USER=oracle)))) Connection ID: 00000B240000000B Socket Id: 15 Operation: Receive Multiplex: ON Session Id: 8362785DE4FB0B19E034080020F793E1 Connect Data: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA=(SERVER=shared) (SERVICE_NAME=sales.us.acme.com)(CID=(PROGRAM=)(HOST=sales-server) (USER=oracle)))) Connection ID: 00000B1F00000008 Socket Id: 15 Operation: Receive Multiplex: ON Session Id: 8362785DE4F90B19E034080020F793E1 Connect Data: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA=(SERVER=shared) (SERVICE_NAME=sales.us.acme.com)(CID=(PROGRAM=)(HOST=sales-server) (USER=oracle)))) ************************************************************************* * Trace Assistant has completed * *************************************************************************
Example 16-14 shows output for connection ID 00000B1F00000008
from the -li 00000B1F00000008
option.
Example 16-14 trcasst -li Output
************************************************************************* * Trace Assistant * ************************************************************************* <--- Received 246 bytes - Connect packet Current NS version number is: 310. Lowest NS version number can accommodate is: 300. Global options for the connection: Can receive attention No attention processing Don't care Maximum SDU size: 8192 Maximum TDU size: 32767 NT protocol characteristics: Test for more data Test operation Full duplex I/O Urgent data support Generate SIGURG signal Generate SIGPIPE signal Generate SIGIO signal Handoff connection to another Line turnaround value: 0 Connect data length: 188 Connect data offset: 58 Connect data maximum size: 512 Native Services wanted NAU doing O3LOGON - DH key foldedin Native Services wanted NAU doing O3LOGON - DH key foldedin Cross facility item 1: 0 Cross facility item 2: 0 Connection id: Ox00000B1F00000008 (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA=(SERVER=shared)(SERVICE_NAME=sales.us.acme.com) (CID=(PROGRAM=)(HOST=sales-server)(USER=oracle)))) ---> Send 114 bytes - Accept packet Accepted NS version number is: 310. Global options for the connection: No attention processing Don't care Accepted maximum SDU size: 8192 Accepted maximum TDU size: 32767 Connect data length: 0 Native Services wanted NAU doing O3LOGON - DH key foldedin Native Services wanted NAU doing O3LOGON - DH key foldedin Connection Time out: 1000 Tick Size: 100 Reconnect Data: (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=34454)) Session Id: 8362785DE4F90B19E034080020F793E1 <--- Received 164 bytes - Data packet Native Services negotiation packet version#: 135290880 Service data packet #0 for Supervisor has 3 subpackets Subpacket #0: Version #135290880 Subpacket #1: 0000000000000000 Subpacket #2: DEADBEEF0003000000040004000100010002 Service data packet #1 for Authentication has 3 subpackets Subpacket #0: Version #135290880 Subpacket #1: UB2: 57569 Subpacket #2: FCFF Service data packet #2 for Encryption has 2 subpackets Subpacket #0: Version #135290880 Subpacket #1: 0000000000 Service data packet #3 for Data Integrity has 2 subpackets Subpacket #0: Version #135290880 Subpacket #1: 0000 ---> Send 143 bytes - Data packet Native Services negotiation packet version#: 135290880 Service data packet #0 for Supervisor has 3 subpackets Subpacket #0: Version #135290880 Subpacket #1: 0000 Subpacket #2: DEADBEEF00030000000200040001 Service data packet #1 for Authentication has 2 subpackets Subpacket #0: Version #135290880 Subpacket #1: FBFF Service data packet #2 for Encryption has 2 subpackets Subpacket #0: Version #135290880 Subpacket #1: UB1: 0 Service data packet #3 for Data Integrity has 2 subpackets Subpacket #0: Version #135290880 Subpacket #1: UB1: 0 <--- Received 48 bytes - Data packet Set protocol (TTIPRO) Operation 01 (con) Receive protocol version=6 Destination platform: SVR4-be-8.1.0 ---> Send 156 bytes - Data packet Set protocol (TTIPRO) Operation 01 (con) Send protocol version=6 Originating platform: SVR4-be-8.1.0 <--- Received 49 bytes - Data packet Set datatypes (TTIDTY) ---> Send 38 bytes - Data packet Set datatypes (TTIDTY) <--- Received 245 bytes - Data packet Start of user function (TTIFUN) Get the session key (OSESSKEY) ---> Send 161 bytes - Data packet Return opi parameter (TTIRPA) ... ************************************************************************* * Trace Assistant has completed * *************************************************************************
The type of statistics gathered is approximately on how many TTC calls, packets and bytes were sent and received between the network partners. Example 16-15 shows typical trace file statistics from the -s
option.
Example 16-15 trcasst -s Output
************************************************************************* * Trace Assistant * ************************************************************************* ---------------------- Trace File Statistics: ---------------------- Total number of Sessions: 3 DATABASE: Operation Count: 0 OPENS, 21 PARSES, 21 EXECUTES, 9 FETCHES Parse Counts: 9 PL/SQL, 9 SELECT, 0 INSERT, 0 UPDATE, 0 DELETE, 0 LOCK, 3 TRANSACT, 0 DEFINE, 0 SECURE, 0 OTHER Execute counts with SQL data: 9 PL/SQL, 0 SELECT, 0 INSERT, 0 UPDATE, 0 DELETE, 0 LOCK, 0 TRANSACT, 0 DEFINE, 0 SECURE, 0 OTHER Packet Ratio: 6.142857142857143 packets sent per operation Currently opened Cursors: 0 Maximum opened Cursors : 0 ORACLE NET SERVICES: Total Calls : 129 sent, 132 received, 83 oci Total Bytes : 15796 sent, 13551 received Average Bytes: 122 sent per packet, 102 received per packet Maximum Bytes: 1018 sent, 384 received Grand Total Packets: 129 sent, 132 received ************************************************************************* * Trace Assistant has completed * *************************************************************************
If you are still unable to resolve your problems, or if you are requested to contact Oracle Support Services to report the error, please have the following information at hand:
The hardware and operating system release number on which the application is running
The up-to-five-digit release number of all the Oracle networking products involved in the current problem
The third-party vendor and version you are using
If you encountered one or more error codes or messages, the exact code numbers and message texts in the order they appeared
The kind of links that exist between the client and server
A description of what does work
The exact error message, if there is one
An Net8 Services trace, if possible; if not, the log file is sufficient