Release 8.0.5 for Windows NT and Windows 95/98
A64419-01
Library |
Product |
Contents |
Index |
| Net8
Getting Started
Release 8.0.5 for Windows NT and Windows 95/98 A64419-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:
|
Note: A supported third-party network transport layer must be also installed and tested. |
To verify proper installation:
Follow the instructions in "Verifying
Installation" in Chapter 3, "Installation
Overview"
|
Note: You may need assistance from the server administrator to follow the instructions in this section. |
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:
When a client application establishes the first Net8 connection, the Net8 parameters are read from SQLNET.ORA file and initialized. Subsequently, if the same client application establishes some more Net8 connections, the SQLNET.ORA file is not read and any changes that were made to the SQLNET.ORA file after the first Net8 connection will not be used. For the new changes to the SQLNET.ORA file to take effect, you have to exit the client application and bring it up again. The behavior on the server side does not change from the previous versions. Any changes to the SQLNET.ORA file will be reflected in subsequent connections.
Client
side tracing
If theTRACE_UNIQUE_CLIENT parameter in SQLNET.ORA file is not enabled,
then all client applications will share the same trace file. If the TRACE_UNIQUE_CLIENT
parameter is enabled in SQLNET.ORA file, then each client application will
have a unique trace file. In both the above cases, the trace statements
will have a prefix in the form of (x), where 'x' is some number. All the
trace statements belonging to one connection will have the same prefix.
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.
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:
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/98 |
|
NT.RGS |
Windows NT |
A missing protocol adapter driver usually produces the following errors in the SQLNET.LOG or any client trace file:
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:
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:
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:
C:\> LSNRCTL80 LSNRCTL> STATUS LISTENER_NAME
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.
Problems 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:
The LSNRCTL80 STAT output looks something like:
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. If 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 Support Services to report the error. See "Contact
Us" for info on how to contact Oracle Support Services.
