Troubleshooting
This appendix describes how to resolve problems that
can arise when you use Oracle Network Products. Specifically, this appendix
covers the following topics:
Diagnosing SQL*Net
If you just completed installing and configuring your
SQL*Net product and an attempt to make a basic peer-to-peer connection
returns an Oracle error, this section may help you diagnose the cause of
the problem.
This section helps you determine which parts of
SQL*Net do function properly rather than the parts that do not work. This
section helps you determine if the problem is:
-
Oracle software
-
networking layer
-
operating system layer
Specifically, this section covers:
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:
-
Bulletins through the GSX Problem/Solution Database Oracle Metalink Web
Site at http://support.oracle.com. If this is your first visit:
-
Select Registration.
-
Select OracleMercury or OracleMetalink.
-
Select Technical Support Knowledge Base.
-
Select only the Problem/Solution Database.
-
Oracle Network Products Troubleshooting
Guide
-
Oracle Worldwide Customer Support
Understanding Proper SQL*Net Installation
SQL*Net 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 client
machines:
-
SQL*Net version 2.3
-
Protocol Specific Adapter (If you are using TCP/IP, install the Oracle
TCP/IP Protocol Adapter, etc.)
| Note: A supported
third party network protocol software must also be installed and tested. |
To verify proper installation:
Follow the instructions in "Verifying
Installation" in Chapter 3, "Installation
Overview".
Server Diagnostics
| Note: You may
need assistance from the server administrator to follow the instructions
in this section. |
Answer the questions below:
-
Is any other system (workstations/servers) able to connect to the server
using SQL*Net?
-
Have there been any changes made to the server, database, or SQL*Net listener
recently?
-
Has your server been up and running for some time?
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 SQL*Net on the server involves two steps:
Step 1: Verify the Database Is Running
To check that the database is up:
Log into the database using SQL*Plus or Server
Manager and connect with a valid username/password. For example:
C:\>SQLPLUS SYSTEM/MANAGER
A Connected message appears.
If you receive the following errors, have your
server administrator assist you:
-
ORA-1017: invalid U/P
-
ORA-1034: Oracle not available
Step 2: Perform a Loopback Test
Loopback test requirements:
-
You must have one of each of these files: LISTENER.ORA, SQLNET.ORA, and
TNSNAMES.ORA exist in the ORACLE_HOME\NETWORK\ADMIN directory.
-
In the SQLNET.ORA file, set the AUTOMATIC_IPC parameter to off (AUTOMATIC_IPC=OFF)
in order to turn off IPC.
If it is on, the loopback is performed through
IPC (Interprocess Communication) instead of the connection going out of
the network card with the protocol adapter, which defeats the purpose of
the loopback test.
To perform a loopback test:
-
Follow the instruction in "Testing the Configuration
on the Server" in Chapter 4, "Configuration"
to start the listener and perform a loopback test.
If the loopback test continues to fail, continue
to Step 2.
If the loopback test passes, skip to Step 3.
-
Check the Problem/Solution Database Web Site at http://support.oracle.com
for more specific information on the error received or contact Oracle
Worldwide Support.
Client Diagnostics
At this point, you assume or know the server's SQL*Net
listener is functioning properly because you answered yes to one or more
of the following statements:
-
I verified a loopback test on the server and the connection worked.
-
I have other machines (servers/workstation) connecting to this same Oracle7
database using SQL*Net.
-
Connections from this workstation worked until we made changes to this
machine (that is, installed new products, modified the network configuration,
and so on).
To perform diagnostics on the client:
-
Check that the underlying protocol stack (such as TCP/IP) is installed
and a supported version is approved for use with the Oracle Protocol Adapter
of choice.
On the client, Oracle Corporation has numerous
supported vendors.
| Additional Information:
See the Problem/Solution database for bulletins
on Available Network Products for your operating system, using search words
"Available," "Networking," or "Products." |
If you have newer versions of the protocol stack,
then it might still work if the vendors' API has not changed. Such versions,
however, are not supported.
If you are using a Winsock compliant vendor, verify
there are no duplicate copies of the WINSOCK DLL file on the system.
-
Check the base connectivity of the protocol stack. You may need a network
administrator's assistance.
SQL*Net technology is layers above the underlying
network transport stack and is dependent on the underlying network for
a successful connection.
| Protocol |
Connectivity Instructions |
| TCP/IP |
Check that you can use file transfer or terminal
emulation utilities (FTP, TELNET, and PING) from the workstation to the
server where the listener and database reside. |
| SPX |
Check that you can perform a Netware login to
the machine that the database is on. Ensure you can map drives or use other
Novell services such as Print Servers and File Servers on the Network.
Check that the listener service is broadcasting by doing a DISPLAY SERVERS
from the Novell server or any Novell file server on the SPX/IPX network. |
| DECnet |
Check that you can use file transfer and terminal
sessions (NFT and SETHOST). Also, check the DECnet network control program,
which is a database of connectable nodes:
-
NCP SHOW KNOWN NODES
-
NCP LIST KNOWN NODE
|
| Named Pipes |
Check that you can see other computers or servers
on the Microsoft network. Ensure you are able to share drives within the
Microsoft network. |
-
Ensure that the SQL*Net Client and appropriate Oracle Protocol Adapter
have been installed by following the instructions in section, "Understanding
Proper SQL*Net Installation," in this appendix.
-
Ensure the client machine has the following two files: TNSNAMES.ORA and
SQLNET.ORA in the proper directory.
For Windows 3.1x the search order for SQLNET.ORA
and TNSNAMES.ORA is as follows:
-
current working directory from where an application is executed
-
TNS_ADMIN variable as defined in the ORACLE.INI file
-
ORACLE_HOME\NETWORK\ADMIN if TNS_ADMIN variable is not defined
For Windows NT and Windows 95, the search order for
SQLNET.ORA and TNSNAMES.ORA is as follows:
-
current working directory from where an application is executed
-
TNS_ADMIN environment variable
-
TNS_ADMIN parameter in the registry if the TNS_ADMIN environment variable
is not defined
-
ORACLE_HOME\NETWORK\ADMIN if TNS_ADMIN is not defined
If you have any other working client machines connecting
to your selected Oracle7 database using SQL*Net, 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.
-
Test the SQL*Net layer with SQL*Plus or Server Manager.
It is advised not to use TNSPING. TNSPING works
just like the TCP/IP PING utility. A socket is never created and open.
TNSPING never connects with the Oracle7 database listener. It just checks
to make sure a TNS listener is running on the server side. Therefore, a
working TNSPING can be misleading.
-
If the connection still fails:
-
Use tracing as described in the next section, "SQL*Net
Logging and Tracing," in this appendix.
-
Check the Problem/Solution Database Web Site at http://support.oracle.com
for a specific diagnostics bulletin on the error received.
-
Contact Oracle Worldwide Support.
SQL*Net Logging and Tracing
Both log and trace files are available for you to
use in troubleshooting your network problems.
This section covers:
For server and listener, log files are by default
located in ORACLE_HOME\NETWORK\LOG and trace files are by default
located in ORACLE_HOME\NETWORK \TRACE. For client, log and trace
files are by default located in the current working directory.
Logging
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:
-
Client or Server -- SQLNET.LOG
-
Listener -- LISTENER.LOG
Tracing
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:
-
Client -- SQLNET.TRC or SQLNETthread_id.TRC if the TRACE_ UNIQUE_CLIENT
parameter is used
-
Server -- SERVERthread_id.TRC
-
Listener--LISTENER.TRC
The Difference Between Logging and Tracing
Logging reveals the state of Oracle components at
the time of an error; that is, when an error occurs, it is logged to the
log file. 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, refer to the following documentation
|
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
E, "Configuration Files".
Tracing for Oracle Names Server
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\NETWORK\ADMIN).
| Note: NAMES.ORA
is not created if you are using DDO. If you are using DDO, you must create
the file manually. |
The next time the Names Server is started, a trace
file named NAMESthread_id.TRC is created in directory ORACLE_HOME\NETWORK\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 for SQL*Net
SQL*Net release 2.3 includes a new, optional source
of SQL*Net tracing that uses the Oracle Trace product. Oracle Trace provides
a standard, supported, tracing facility for Oracle products.
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.
In addition to its use in SQL*Net release 2.3, Oracle Trace is also used
to capture data for the Oracle7 database.
Resolving Common Error Messages and Codes
The most common error messages are detailed below:
ORA-12154: Could not resolve service name
Cause: SQL*Net could not find the connect descriptor
specified in the TNSNAMES.ORA file.
Action: After verifying that the database
is up, check the following:
-
Make sure the domain specified by the service_name.domain parameter
in the TNSNAMES.ORA file matches the value for the NAMES.DEFAULT_DOMAIN
parameter in the SQLNET.ORA file.
-
Try setting the TNS_ADMIN configuration parameter to the directory where
the configuration files are stored.
-
If connecting from a login box, do not begin the field for the connect
string with an @ sign. Only use the @ sign if specifying the connect string
in command line mode:
SQLPLUS SCOTT/TIGER@service_name
-
Make sure you have a TNSNAMES.ORA file on the client if you are not using
an Oracle Names Server.
-
Check for multiple copies of the TNSNAMES.ORA file.
By default, TNSNAMES.ORA is located in ORACLE_HOME\NETWORK\ADMIN.
-
Ensure that the configuration files were created with either SQL*Net Easy
Configuration or Oracle Network Manager.
-
If these tools were not used, many syntax errors can exist. The solution
is to re-create the configuration files using SQL*Net Easy Configuration
or Oracle Network Manager.
-
In the TNSNAMES.ORA file, verify:
-
the service name you are specifying in the connect string matches the one
in the TNSNAMES.ORA file.
-
there are no syntax errors, especially stray characters and mismatched
parentheses.
-
If you are not using the MultiProtocol Interchange (MPI), remove the TNSNAV.ORA
file created by Oracle Network Manager.
-
Make sure that there are no duplicate copies of SQLNET.ORA.
-
Turn on client tracing and re-execute the operation.
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\NETWORK\ADMIN\SQLNET.ORA file to TRACE_LEVEL_CLIENT
= 16.
-
If you are using domain names, check your SQLNET.ORA file for the parameter
NAME.DEFAULT_ZONE.
The domain name must be specified in the connect
string if no parameter exists in the SQLNET.ORA file. If you are not using
domain names, then comment out this parameter in the SQLNET.ORA file:
#NAME.DEFAULT_ZONE=domain
If you comment out this parameter, you must also comment
out the NAMES.DEFAULT_DOMAIN parameter:
#NAMES.DEFAULT_DOMAIN=domain
-
For Windows 3.1x, the ORA-12154 error can result from:
-
specifying the service_name (for ORA73WIN.DLL) string instead of
tns:prefix (for ORA6WIN.DLL)
If unsure whether your application uses ORA6WIN.DLL
or ORA73WIN.DLL, specify the tns: prefix. ORA73WIN.DLL accepts the
tns:prefix as well.
-
not using the TNS prefix in the connect string with Server Manager for
both Oracle6 and Oracle7.
-
not having the TNS_ADMIN variable set in the ORACLE.INI file to the directory
where TNSNAMES.ORA and SQLNET.ORA are located.
-
a problem with the file handles being allocated. One symptom of this problem
is that tracing for SQL*Net cannot be turned on.
The workaround to this problem is to close other
Windows applications to allocate more file handles. If you are using Microsoft
Access, a possible workaround is to ensure the application does not have
a lot of objects while establishing a connection.
-
not using SQL*Net V2.1.x when using an application built on DBMS
7.1.x libraries such as Oracle Power Objects. Oracle Power Objects
uses the 7.1 libraries and SQL*Net 2.2 and 2.3 is not guaranteed
to work with applications based on the 7.1 libraries.
ORA-12203:TNS:unable to connect to destination
This message can appear in the following scenarios:
Cause: An invalid TNS service name was supplied
in the connect string.
Action: Verify that the TNS 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: The destination system's listener is
not listening.
Action: Verify that the remote system's
SQL*Net listener is running. Enter:
C:\>LSNRCTL
LSNRCTL>STATUS [listener_name]
where listener_name is the name of the listener
defined in the server's LISTENER.ORA file. It is not necessary to identify
the listener if you are using the default listener, named LISTENER.
If the output indicates the listener is not running,
try starting it with the command:
LSNRCTL>START [listener_name]
Cause: There are underlying network transport
problems.
Action: 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\NETWORK\ADMIN (the default) directory or an alternative
path, as explained in "Client Diagnostics".
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 |
| WINDOWS.RGS |
Windows 3.1x |
| 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: The (HOST=host_name) for TCP/IP or (SERVICE=tns_application)
for SPX are not consistent on the clients and server machines.
Action: Ensure the (HOST=host_name) for
TCP/IP or (SERVICE=tns_application) for SPX are 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.
ORA-12203: TNS: unable to connect to destination and ORA-12154: TNS: could
not resolve service name Using 16-bit Applications on Windows NT
Cause: SQL*Net 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 SQL*Net listener is running. Enter:
C:\>LSNRCTL
LSNRCTL>STATUS [listener_name]
where listener_name is the name of the listener
defined in the LISTENER.ORA file. It is not necessary to identify the listener
if you are using the default listener, named LISTENER.
If the output indicates the listener is not running,
try starting it with the command:
LSNRCTL>START [listener_name]
-
Ensure the TNSNAMES.ORA file is in the correct location.
By default, TNSNAMES.ORA is located in ORACLE_HOME\NETWORK\ADMIN.
-
Verify that configuration files were created with either SQL*Net Easy Configuration
or Oracle Network Manager.
If these tools were not used, many syntax errors
may exist. The solution is to re-create the configuration files using SQL*Net
Easy Configuration or Network Manager.
-
Verify you are not using 16-bit SQL*Net SPX on Windows NT, as it is not
supported, by ensuring the NTS.DLL file does not exist.
-
If connecting from a login box, make sure you are not placing an @ symbol
in front of your connect service name. For example, if your valid service
name is ORCL, it actually looks for @ORCL in your TNSNAMES.ORA file.
ORA-3121: No interface driver connection - function not performed on Windows
NT
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: No connect string has been specified
from a client machine with no Oracle database.
Action: Specify a connect string.
Resolving Oracle Names Server Problems
Problems with Oracle Names Server occur because:
Client Connections Not Established
The NAMESCTL 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 the Oracle Names Server
for alias V734.world through the NAMESCTL utility:
-
C:\>NAMESCTL
Oracle Names Control for Solaris: Version 2.0.4.0.0 - Production on 28-AUG-97
14 :44:15
Copyright (c) Oracle Corporation 1995. All rights reserved.
Currently managing name server "NS453EAE"
Version banner is "Oracle Names for Solaris: Version 2.0.4.0.0 - Production"
Welcome to NAMESCTL, type "help" for information.
-
NAMESCTL>QUERY V734.WORLD *
Total response time: 0.10 Message 707 not fo
Response status: normal, successful completion
Authoritative answer: yes
Number of answers: 3
TTL: 1 Message 700 not fo
Answers:
data type is "tos.npd.omd"
Syntax is CTEXT: "database"
data type is "host.nm.omd"
Syntax is TEXT: "netsol3"
data type is "a.smd"
Syntax is ADDR:
...(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(DEV=11)(HOST=
machine1)(PORT=1526)))(CONNECT_DATA=(SID=V732)))
The "a.smd" data type that stores the address for
V734.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).
Service Is Not Resolved
When a service is not resolved through an Oracle Names
Server:
-
Make sure that the parameter USE_PLUG_AND_PLAY_listener_name (is
defaulted to LISTENER) is set to TRUE in the LISTENER.ORA file on the server.
-
Make sure that the parameter GLOBAL_DBNAME is set for each database in
the SID_LIST_listener_name (listener_name is defaulted to
LISTENER) section in the LISTENER.ORA file on the server.
-
Use the LSNRCTL STAT command to see if the database you are trying to connect
to is registered with the Names Server. The database is registered with
the Names Server if the word Registered appears next to the database SID
in the Services Summary section of the output.
The LSNRCTL STAT output looks something like:
LSNRCTL for Solaris: Version 2.3.2.1.0 - Production on 04-DEC-96 14:41:04
Copyright (c) Oracle Corporation 1994. All rights reserved.
Connecting to (ADDRESS=(PROTOCOL=TCP)(HOST=machine1)(PORT=1526))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Solaris: Version 2.3.4.0.0 - Production
Start Date 28-AUG-97 14:40:54
Uptime 0 days 0 hr. 0 min. 9 sec
Trace Level off
Security OFF
SNMP OFF
Listener Parameter File
D:\ORANT\network\admin\listener.ora
Listener Log File
D:\ORANT\network\log\listener.log
Listener Trace File
D:\ORANT\network\trace\listener.trc
Services Summary...
V732(Registered) has 1 service handler(s)
The command completed successfully
-
Query the Names Server through the NAMESCTL utility for the SQL*Net service
you are using. In the output, check the address for the service you are
using and make sure it is correct. See the previous section "Client
Connections Not Established".
SQL*Net Troubleshooting Hints and Tips from the Field
Below are some SQL*Net tips you may find helpful when
you are unable to diagnose a problem:
-
Try using the node or network address during configuration instead of the
name of the server machine. This eliminates any internal lookup problems
(and makes the connection slightly faster).
| Protocol |
Node Address Instructions |
| TCP/IP |
Use the internet protocol address, for example,
198.32.3.5
Change the (HOST = server_name) line in TNSNAMES.ORA
to the internet protocol address; for example, (HOST = 198.32.3.5). |
| DECnet |
Use the node address, for example, 198.43. The
Network Control Program (NCP) can provide this information from the command
LIST NODE node_name.
Change the (NODE = node_name) line in the TNSNAMES.ORA
file to the node number, for example, (NODE = 193.43) |
-
Ensure the VSL.INI file is present before making a 16-bit SQL*Net TCP/IP
for Windows connection.
-
Understand the SPX connection issues.
The workstation that is requesting a connection
to be made with a remote Oracle SPX 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.
-
Perform a loopback test on the server and FTP the files TNSNAMES.ORA and
SQLNET.ORA to the client.
-
Comment out unnecessary SQLNET.ORA parameters.
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)
-
Set the AUTOMATIC_IPC parameter to OFF in the client SQLNET.ORA file to
reduce the errors in the trace file. IPC (interprocess communication) is
only an option on the machine where the Oracle Server is running, but SQL*Net
by default attempts to use the IPC driver if AUTOMATIC_IPC is set to ON
in the SQLNET.ORA file.
-
Check what is between you and the server. If it is a wide area network,
identify any intermediate systems that are not working correctly. If all
machines are fine, the problem may be a timing issue. Timing issues are
associated with ORA-12203, ORA-12535, or ORA-12547 errors in the client
log files.
To resolve this, try speeding up the connection
by using exact addresses instead of names and increase the CONNECT_TIMEOUT_LISTENER
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.
Questions to Ask When Troubleshooting
Below are some questions to ask yourself when diagnosing
a problem:
-
Do all machines have a problem or is it just one?
If one machine works and another does not, and
you are confident that the same software (Oracle and third party products)
is installed, swap 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.
-
What kind of links are between the client and the server, for example,
X.25, Integrated Services Digital Network (ISDN), Token Ring, or leased
line?
Sniffers and LAN Analyzers are useful for intermittent
failing connections or detecting time-outs and re-sent packets. You can
also see what side of the conversation is waiting for a response.
-
Does the third-party application fail, but Oracle applications work?
-
Do transport layer connections work?
Contacting Oracle Worldwide Customer Support
How to Contact Oracle Worldwide Customer Support
Oracle Worldwide Customer Support can be contacted
as follows:
| Location |
Contact |
| United States of America |
Telephone (1) (650) 506-1500 |
| Europe |
Telephone (1) (44) (1344) 860-160 |
| Outside the United States and Europe |
Your Oracle sales representative |
| Worldwide |
Visit: http://www.oracle.com/support/ |
For further information on how to contact Oracle Worldwide
Customer Support, please refer to the included Customer Support Information
Booklet.
Before You Call for Assistance
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:
-
The hardware and operating system release number on which your application(s)
is running.
-
The release numbers (up to five digits in release) of all Oracle networking
products involved in the current problem.
-
The third-party vendor and version you are using.
-
The kind of links that are between the client and server.
-
A description of what does work.
-
The exact error message.
-
A SQL*Net trace if possible. If not, the log file is sufficient.
