| Oracle Network Products Getting Started for Windows Platforms |  Library |
 Product |
 Contents |
 Index |
| Oracle Network Products Getting Started for Windows Platforms | Library |
Product |
Contents |
Index |
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\NETWORK\ADMIN.
The client trace file shows a secondary error code. To turn on client tracing, add to (or increase) the variable TRACE_LEVEL_CLIENT in the ORACLE_HOME\NETWORK\ADMIN\SQLNET.ORA file.
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=domainIf you comment out this parameter, you must also comment out the NAMES.DEFAULT_DOMAIN parameter:
#NAMES.DEFAULT_DOMAIN=domain
If unsure whether your application uses ORA6WIN.DLL or ORA73WIN.DLL, specify the tns: prefix. ORA73WIN.DLL accepts the tns:prefix as well.
The workaround to this problem is to close other Windows applications to allocate more file handlers. If you are using Microsoft Access, a possible workaround is to ensure the application does not have a lot of objects and then establish a connection. Afterwards, you may be able to establish a connection with an application with more objects.
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:
Cause: The destination system's listener is not listening.Action: Verify that the remote system's SQL*Net listener is running. Enter:
LSNRCTL
LSNRCTL>STATUS [listener_name]where listener 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 ORACLE_HOME\NETWORK\ADMIN directory.
Action: Make sure the Windows workstation has its TNSNAMES.ORA file located in ORACLE_HOME\NETWORK\ADMIN.
If your workstation's ORACLE.INI file has a parameter named TNS_ADMIN, ensure that it points to the directory in which the TNSNAMES.ORA file is located.
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 |
Action: Ensure the (HOST=host_name) for TCP/IP and (SERVICE=tns_application) for SPX are the same on the server and client workstations.
For SPX setups, the name must be the same on the server and client workstations.
Action: After verifying that the database is running, check the following:
LSNRCTL
LSNRCTL>STATUS [listener_name]where listener 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]
By default, TNSNAMES.ORA is located in ORACLE_HOME\NETWORK\ADMIN.
If they 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.
Action: Do not use the following prefixes in the connect string.
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:
A problem can be identified if you slowly test each network layer.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:
The architecture of TNS is comprised of two software components that need to be installed on both the server and all client machines:
|
|
Follow the instructions in "Verifying Oracle Network Products Setup".
|
|
Diagnosing SQL*Net on the server involves:
If you receive the following errors, have your server administrator assist you:
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.
If the loopback test continues to fail, continue to Step 3.
On the client, Oracle has numerous supported vendors, including several versions that we have certified.
|
|
If you have newer versions of the underlying network layer, then it might still work if the vendors' API has not changed.
For TCP/IP, sometimes vendors provide two interfaces, a proprietary one and a Winsock compliant one. Winsock is a standard that provides a common set of network calls. In theory, any vendor who supplies a Winsock compliant interface is suitable for Oracle software. In practice, the quality of the implementations varies from supplier to supplier. Therefore, make sure that the TCP/IP layer is a proper copy and not a less expensive clone, as the API can be different. Also, there are many shareware versions that are Winsock compliant that Oracle does not support, but which may work.
If you are using a Winsock compliant vendor, verify there are no duplicate copies of the WINSOCK.DLL file are on the system.
SQL*Net technology is layers above the underlying network transport stack and are dependent on the underlying network for a successful connection.
The search order for SQLNET.ORA and TNSNAMES.ORA is as follows:
It is advised not to use TNSPING. TNSPING works just like the TCP/IP ping utility. A socket is never created and open. The TNSPING never connects with the Oracle7 Server listener. It just checks to make sure a TNS listener is present on the server side. Therefore, a working TNSPING can be misleading.
Log files are by default located in ORACLE_HOME\NETWORK\ADMIN \LOG and trace files are by default located in ORACLE_HOME\NETWORK\ADMIN \TRACE.
|
|
Edit the SQLNET.ORA and LISTENER.ORA files and set the following:
TRACE_LEVEL_CLIENT=16
TRACE_DIRECTORY_CLIENT= <Directory where trace is written>
LOG_DIRECTORY_CLIENT = <Directory where log file is written>
Oracle Trace is a general-purpose data collection product that has been introduced with 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 Oracle Server release 7.3.
|
|
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 NetWare Core Protocol (NCP) lookup request to the server it is currently attached to with its primary connection. This does not require the workstation to be logged into that NetWare server as a registered NetWare user. It simply requires that a workstation NCP connection has been established with the server.
When SQL*Net SPX requests a connection with a remote Oracle SPX listener, the workstation provides the following items of information to the NetWare server when requesting this lookup:
|
| 259 DEC (0x103 hex) |
|
| Oracle SPX listener name |
|
| Network Address |
If this combination of information is not present in the Server Information Table, 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 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)
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.
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.
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.
For further information on how to contact Oracle Worldwide Customer Support please refer to the included Customer Support Information Booklet.
 Prev Next |
 Copyright © 1996 Oracle Corporation. All Rights Reserved. |
Library |
Product |
Contents |
Index |