Net8 Getting Started Release 8.0.4 for Windows NT and Windows 95 A55913-01 |
|
This appendix describes how to resolve problems that may arise when you use Net8 products.
Specific topics discussed are:
If you have just completed installing and configuring your Net8 product and an attempt to make a basic peer-to-peer (single protocol/single community 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 Net8 with an error number or message that is not always indicative of the actual problem.
This section helps you determine which parts of Net8 do function properly rather than the parts that do not work. This section helps you determine if the problem is:
A problem can be identified if you progressively test various network layers.
For more information on specific error messages or technical bulletins on errors received when performing these diagnostics test, please check the following resources available to you:
Net8 is Oracle Corporation's remote data access software. It enables both client-server and server-server communication (with applications residing on different machines communicating as peer applications) across any network.
The architecture of TNS is comprised of two software components that need to be installed on both the server and all the client machines:
To verify proper installation:
Follow the instructions in "Verifying Installation and Setup" in Chapter 3, "Understanding Post Installation Tasks".
Answer the questions below:
If you answer yes to any of the above questions/statements, skip this section and continue to "Client Diagnostics" in this appendix. If you are not sure or answered no to any of the above questions, please continue.
Diagnosing Net8 on the server involves:
To check that the database is up:
Log on to the database using SQL*Plus or Server Manager and connect with a valid username/password. For example:
C:\> 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:
If the loopback test continues to fail, continue to Step 3.
If the loopback test passes, skip to "Client Diagnostics" in this appendix.
At this point, you know the Net8 server side network listener is functioning properly, because you were able to answer Yes to any of the following statements:
To perform diagnostics on the client:
Net8 technology depends upon the underlying network for a successful connection.
The search order for SQLNET.ORA and TNSNAMES.ORA is as follows:
If you have any other working client machines connecting to your selected Oracle8 database using Net8, back up your existing files and copy both the working TNSNAMES.ORA and SQLNET.ORA files from the working machine onto the non-working client workstations. This eliminates the possibility of errors in the files.
It is advised not to use TNSPNG80. TNSPNG80 works just like the TCP/IP PING utility. A socket is never created and open. The TNSPNG80 never connects with the network listener. It just ensures network listener is present at the server side.
Both log and trace files are available for you to use in troubleshooting your network problems.
This section covers:
For server and network listener, log files are by default located in ORACLE_HOME\NET80\LOG and trace files are by default located in ORACLE_HOME\NET80 \TRACE. For client, log and trace files are by default located in the current working directory.
All errors encountered in Oracle network products 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.
The default log file names are:
Tracing can be used to examine and diagnose application connections across the network. The trace facility allows a network or database administrator to obtain more information on the internal operations of the components of an Oracle application network than is provided in a log file. Tracing an operation produces a detailed sequence of statements that describe the events as they are executed. All trace output is directed to trace output files that can be evaluated to identify the event that led to an error.
Default trace file names are:
Logging is used to log important events for Oracle components. For example, the network listener log file logs version number, protocols it is listening for, connection establishments, errors, and so on. However, tracing describes all software events as they occur; that is, even when an error is not occurring. Information is posted into the trace file to show what is happening in the software. Thus, tracing provides additional information about events whether or not there is an error.
Additional Information:
For more specific details about SQL*Net logging and tracing, see Chapter 10, "Troubleshooting Net8", of the Oracle Net8 Administrator's Guide. |
Tracing and logging parameters are added to the SQLNET.ORA and LISTENER.ORA files. These parameters are described in "Using SQLNET.ORA Logging and Tracing Parameters" and "Using LISTENER.ORA Control Parameters" in Appendix C, "Configuration Files".
In some situations, it may be necessary to set tracing on for the Oracle Names Server. Tracing is set on by adding the parameter NAMES.TRACE_LEVEL = 16 in the NAMES.ORA file on the server (this file is located in ORACLE_HOME\NET80\ADMIN).
The next time the Names Server is started, a trace file named NAMESTHREAD_ID.TRC is created in directory ORACLE_HOME\NET80\TRACE.
If a client connection is not properly established, client tracing can give more information. Client tracing is set by adding the TRACE_LEVEL_CLIENT = 16 parameter to the SQLNET.ORA file.
Oracle Trace allows your trace information to be managed through an Oracle Enterprise Manager console in an Oracle Trace repository.
Oracle Trace is a general-purpose data collection product that is part of the Oracle Enterprise Manager systems management product family. Oracle Trace allows Oracle products to collect data for a variety of uses, such as performance monitoring, diagnostics, and auditing.
Additional Information:
See the Oracle Enterprise Manager Oracle Trace User's Guide for information about using Oracle Trace. |
Use Trace Assistant to interpret your *.TRC files.
This utility will help you diagnose and troubleshoot network problems by giving you a better understanding of:
Follow the instructions in Section "10.4.3 Using the Trace Assistant to Examine Your Trace Files", in the Oracle Net8 Administrator's Guide to run the Trace Assistant.
The error messages most commonly experienced by Oracle networking product users are:
ORA-12154: TNS: Could not resolve service name
ORA-12203:TNS:unable to connect to destination
ORA-3113: end of file communication channel
ORA-3121: No interface driver connection - function not performed
If you are using the Oracle Names Server, go to "Resolving Oracle Names Server Problems" in this appendix.
Cause: Net8 could not find the connect descriptor specified in the TNSNAMES.ORA file.
Action: After verifying that the database is turned on, check the following:
SQLPLUS SCOTT/TIGER@
SERVICE_NAME
By default, TNSNAMES.ORA is located in ORACLE_HOME\NET80\ADMIN.
The client trace file shows a secondary error code. To turn on client tracing, add or modify the variable TRACE_LEVEL_CLIENT in the ORACLE_HOME\NET80\ADMIN\SQLNET.ORA file to TRACE_LEVEL_CLIENT = 16.
ORA-12203 error is a generic error that often shields secondary errors. For this reason, check the latest SQLNET.LOG file located in ORACLE_HOME\NET80\LOG directory for secondary ORA messages. If after analyzing the log file you determine there are no secondary errors, determine if the problem may be caused by on the following scenarios:
Cause: The incorrect Oracle Protocol Adapter for the selected networking protocol is installed.
Action: Ensure the correct DLL is installed by viewing the RGS file in the ORACLE_HOME\ORAINST directory:
File | Operating System |
---|---|
WIN95.RGS |
Windows 95 |
NT.RGS |
Windows NT |
A missing protocol adapter driver usually produces the following errors in the SQLNET.LOG or any client trace file:
ORA-12203
ORA-12538
ORA-00508
Cause: An invalid service name was supplied in the connect string.
Action: Verify that the service name supplied in your connect string exists in your TNSNAMES.ORA file and the ADDRESS information for that TNS service name is valid:
Is the HOST or SERVICE name correct? Is the PORT specified correct?Cause: Net8 could not find the connect descriptor specified in the TNSNAMES.ORA file.
Action: After verifying that the database is running, check the following:
Verify the Net8 network listener is running. Enter:
LSNRCTL80 LSNRCTL> STATUS LISTENER_NAME
where LISTENER_NAME is the name of the network listener defined in the LISTENER.ORA file. It is not necessary to identify the network listener if you are using the default network listener, named LISTENER.
If the output indicates the network listener is not running, try starting it with the command:
LSNRCTL> START LISTENER_NAME
By default, TNSNAMES.ORA is located in ORACLE_HOME\NET80\ADMIN.
Cause: The destination system's network listener is not listening.
Action: Verify that the remote system's network listener is running. Enter:
where LISTENER_NAME is the name of the network listener defined in the server's LISTENER.ORA file. It is not necessary to identify the network listener if you are using the default network listener, named LISTENER.
If the output indicates the network listener is not running, try starting it with the command:
LSNRCTL> START LISTENER_NAME
Cause: There are underlying network transport problems.
Action: Verify with utilities supplied with the networking protocol being used that the protocol itself is functional. For example, with TCP/IP, try to PING the remote system.
Cause: TNSNAMES.ORA file is not located in the proper directory.
Action: Make sure the TNSNAMES.ORA file is located in ORACLE_HOME\NET80\ADMIN (the default) directory or an alternative path, as explained in "Client Diagnostics".
Cause: The (HOST=SERVER_NAME) for TCP/IP or (SERVICE=TNS_APPLICATION) for SPX are not consistent on the clients and server machines.
Action: Ensure the (HOST=SERVER_NAME) for TCP/IP or (SERVICE=TNS_APPLICATION) for SPX are the same on the server and client workstations.
For TCP/IP setups, make sure that the HOST parameter in the LISTENER.ORA on the server and 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.
For SPX setups, the name must be the same on the server and client workstations.
Cause: The descriptor in the TNSNAMES.ORA file for the Oracle LU6.2 Protocol Adapter does not have the value for PLU_LA in upper case. This is irrespective of the case used in the SIDEINFO.NSD file for the symbolic destination name. For example:
os2= (DESCRIPTION= (ADDRESS=(PROTOCOL=LU62) (PLU_LA=os2)))
results in this error.
Action: Change the value to uppercase. For example:
os2= (DESCRIPTION= (ADDRESS=(PROTOCOL=LU62) (PLU_LA=OS2)))
where os2 is defined as the SYMBOLIC DESTINATION NAME in the SIDEINFO.NSD file.
An ORA-3113 means that communications were lost for an unexpected reason. It is usually followed by a:
ORA-3114: not connected to ORACLE
Cause: The Oracle shadow process on the server died unexpectedly.
Action: Check if the SIDALRT.LOG file in ORACLE_HOME\RDBMS80\TRACE on the server to see if any other Oracle errors occurred.
Cause: Machine crash or network failure at the server side.
Cause: Two servers with the same host names or IP addresses on the same network.
Action: To find the duplicate addresses turn off the machine that is receiving the error, PING its IP address. If the PING responds, then you have to find the offending machine.
Cause: The TOKEN RING card has the Shared RAM size set to 8KB rather than 16KB.
Action: If you are using a TOKEN RING card, check the shared buffer size and try increasing it.
Cause: An unexpected end-of-file was processed on the communication channel. The TCP/IP retransmission count on Windows 95 and Windows NT has a default value of 5. This means that the send side retransmits the packet five times or until it gets an acknowledgment. The timeout for each retransmission is two times the timeout for the previous retransmission (exponential backoff). With the default value of 5, the send side retransmits 5 times (approximately 15 seconds) and if it does not get an acknowledgment, it assumes that the other side is down and closes the connection. If the link goes down for a minute or two the Net8 client receives this error.
Action: Modify the retransmission count.
Please see your Microsoft-specific operating system manual for more information on tuning the Microsoft TCP/IP software
Cause: This is caused from using a SQL*Net version 1 prefix in the connect string.
Action: Do not use the following prefixes in the connect string.
Cause: If you only specify the user name and password from a client machine with no local Oracle database installed.
Action: Specify a connect string.
Names Server ProblemsProblems with Oracle Names Server occur because:
The NAMESCTL80 utility provides the QUERY command, which queries the existence or contents of an object (for example, a database) stored in the Names Server. This command can be useful in situations where a client connection is not properly established.
For example, you can query an Oracle Names Server for INVENTORYDB.WORLD alias through the NAMESCTL80 utility:
C:\> NAMESCTL80 NAMESCTL> QUERY INVENTORYDB.WORLD *
The sample output looks like:
Total response time: 0.01 Response status: normal, successful completion Authoritative answer: yes Number of answers: 1 TTL: 1 day ...(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST= INVENTORY)(PORT=1526)))(CONNECT_DATA=(SID=ORCL)))
The "a.smd" data type that stores the address for INVENTORYDB.WORLD allows you to determine if the address is correct (that is, for TCP/IP the host name and the port number must be the same as the ones defined in the LISTENER.ORA file on the server).
When a service is not resolved through an Oracle Names Server:
Registered
appears next to the database SID in the Services Summary section of the output.
The LSNRCTL80 STAT output looks something like:
LSNRCTL80 for 32-bit Windows: Version 8.0.4.0.0 - Production on 25-NOV-97 18:51:15 (c) Copyright 1997 Oracle Corporation. All rights reserved. Connecting to (ADDRESS=(PROTOCOL=IPC)(KEY=oracle.world)) STATUS of the LISTENER ------------------------ Alias LISTENER Version TNSLSNR80 for 32-bit Windows: Version 8.0.4.0.0 - Production Start Date 24-NOV-97 14:30:27 Uptime 1 days 4 hr. 20 min. 50 sec Trace Level off Security ON SNMP OFF Listener Parameter File D:\orant\NET80\admin\listener.ora Listener Log File D:\orant\NET80\log\listener.log Services Summary... ORCL has 1 service handler(s) extproc has 1 service handler(s) The command completed successfully
You receive the following error message if external procedures are not correctly configured for 3GL programming language in a PL/SQL environment, the Image Cartridge, the Time Series Cartridge, or the VIR Cartridge.
ORA-28575: unable to open RPC connection to external procedure agent
ORA-06512: at "APPLICATIONS.OSEXEC", line 0
ORA-06512: at "APPLICATIONS.TEST", line 4
ORA-06512: at line 2
Ensure external procedures are properly configured, these error messages display. Follow the procedures in "Configuring External Procedure Calls" in Chapter 8, "Performing Advanced Configuration".
Below are some Net8 tips you may find helpful when you are having difficulty diagnosing the problem:
This eliminates any internal lookup problems (and make the connection slightly faster).
For TCP/IP - Use the internet address, for example, 198.32.3.5
Change the (HOST =SERVER_NAME) line in TNSNAMES.ORA with internet address, for example, (HOST=198.32.3.5).
The workstation that is requesting a connection to be made with a remote network listener must first learn the location of that SPX service in the NetWare IPX network.
The client workstation issues a lookup request for the SPX service. It the service can not be found, an error is sent back to the workstation.
The SQLNET.ORA file may have parameters required for more enhanced uses, such as Dead Connection Detection. Older SQLNET.ORA files can have the Advanced Networking Option (ANO) parameters that do not work for SQL*Net. If these features are not fully configured, a basic connection can fail. The following parameters can be commented out:
SQLNET.AUTHENTICATION_SERVICES (ANO Parameter)
SQLNET.EXPIRE_TIME (Dead Connection Detection Parameter)
SQLNET.CRYPTO_SEED (ANO Parameter)
To resolve this, try speeding up the connection by using exact addresses instead of names and increase the CONNECT_TIMEOUT_LISTENER parameter in the LISTENER.ORA file. The default value for this parameter is 10 seconds.
Below are some questions to ask yourself when diagnosing a problem:
If one machine works and another does not, and you are confident that the same software (Oracle and third party products) is installed, swap over the network cables (if they are close enough) to see if the problem moves. This indicates the problem is something between the client-server and not locally on the PC.
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.
If after reading this appendix, you still cannot resolve your problems, call Oracle Worldwide Customer Support to report the error. Please have the following information at hand: