Note: The information contained in the following summary is for the benefit of the network administrator, who needs to understand what role SQL*Net version 2 plays within the network.
A client application initiates a request for a connection to a remote database (or other network service) by providing a short name for its desired destination. That short name, called a service name, is mapped to a network address contained in a connect descriptor stored in the network configuration file TNSNAMES.ORA or in a database for use by
Oracle Names. For more information on service names and connect descriptors, see "Global Naming Issues" ![[*]](jump.gif)
. See also Understanding SQL*Net.
Note: If the network includes Oracle Names, the service names and associated connect descriptors are stored in a database that is accessed by the Names servers, and the TNSNAMES.ORA file is not needed. Similarly, if a native names adapter (such as NIS) is being used, this information will be stored in the corresponding native name service.
Additional Connection Request If a client application is connected to a server and requires access to another user account on the same server or on another server, most Oracle tools will first disconnect the application from the server to which it is currently connected. Once the disconnection is completed, a connection request to the new user account on the appropriate server is initiated.
Abnormal Connection Termination Occasionally, one of the components below SQL*Net will be disconnected or will abort communications and SQL*Net will not be immediately informed.
During the next SQL*Net data operation, the TNS module will recognize the failure and give SQL*Net a notice to clean up client and server operations, effectively disconnecting the current operation.
Timer Initiated Disconnect or Dead Connection Detection (SQL*Net release 2.1 and later only). Dead connection detection (Keep Alive or Dead Man's Handle) is a feature that allows SQL*Net to identify connections that have been left hanging by the abnormal termination of a client. On a connection with Dead Connection Detection enabled, a small probe packet is sent from server to client at a user-defined interval (usually several minutes). If the connection is invalid (usually due to the client process or machine being unreachable), the connection will be closed when an error is generated by the send operation, and the server process will exit.
This feature minimizes the waste of resources by connections that are no longer valid. It also automatically forces a database rollback of uncommitted transactions and locks held by the user of the broken connection.
All send and receive requests are synchronous. That is, when the client initiates a request, it waits for the server to respond with the answer. It can then issue an additional request.
SQL*Net version 2 adds the capability to send and receive data requests asynchronously. This capability was added to support the Oracle7 multi-threaded server, which requires asynchronous calls to service incoming requests from multiple clients.
The other two exception operations are internal to some products using SQL*Net to resolve network timing issues. SQL*Net can initiate a test of the communication channel, for example, to see if new data has arrived. The reset function is used to resolve abnormal states, such as getting the connection back in synchronization after a break operation has occurred.
Additional Information: For information on SQL*Net version 2 connections with a native connection acceptance method, see the Oracle operating system-specific documentation for that protocol and platform.
Note: Prespawned dedicated servers requires SQL*Net release 2.1 or later, and requires Oracle7 Server release 7.1 or later.
Prestarted dedicated server processes reduce connect time by eliminating the need to create a dedicated server process for each new connection request as it comes to the listener. They also provide better use of allocated memory and system resources by recycling server processes for use by other connections without having to shut down and recreate a server. The use of prestarted dedicated server processes is particularly useful in systems where the Oracle7 Multi-Threaded Server is unsupported, or where the creation of a new server process is slow and resource-intensive.
Figure 2 - 7 shows the role of the network listener in a SQL*Net connection to a server connected to two communities.
Figure 2 - 7. Network Listener in SQL*Net Connection
The steps involved in establishing a connection (as shown in Figure 2 - 7) are:
Step 1. A connection request is made by any client in the TNS network and arrives through one of the communities to which the listener is attached.
Step 2. The network listener identifies that a connection request has arrived in one of its communities.
Step 3. a. The network listener spawns a dedicated server process and passes control of the incoming connection to it, or, b. the address of a shared dispatcher process (multi-threaded server) is provided, and the incoming connection is directed to it, or, c. the incoming connection is redirected to one of the prespawned dedicated server processes.
At the completion of a connection, the network listener continues to listen for additional incoming connections.