Understanding SQL*Net

Contents Glossary Index Home Previous Next

SQL*Net Operations

SQL*Net provides functions, described in the following sections, that belong to the following classifications:

All the functions work with tools and databases that use SQL*Net for distributed processing, although none of them is visible to the user.

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.

Connect Operations

SQL*Net supports two basic connect operations:

Connecting to Servers

The connect operation is initiated during any standard database login between the client application and the server, with information such as the client machine name and username being passed to the remote machine. This information is required to support externally identified logins.

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, in a database for use by Oracle Names, or in native naming service such as NIS or DCE CDS.

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 an Oracle Native Naming Adapter such as NIS or DCE CDS is being used, this information will be stored and retrieved from that native name service.

Disconnecting from Servers

Requests to disconnect from the server can be initiated in the following ways:

User-Initiated Disconnect A user can request a disconnection from the server when a client-server transaction completes. A server can also disconnect from a second server when all server-server data transfers have been completed, and no need for the link remains (the simplest case).

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 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.

Data Operations

SQL*Net supports four sets of client-server data operations:

The concept of sending and receiving data between client and server on behalf of the UPI and OPI is relatively straightforward. A SQL dialogue request is forwarded from the UPI using a send request in SQL*Net. On the server side, SQL*Net processes a receive request and passes the data to the database. The opposite occurs in the return trip from the server.

The basic 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.

Exception Operations

SQL*Net supports three exception operations:

Of these three operations, only the initiation of a break can be controlled by the user. When the user presses the Interrupt key [Ctrl-C] on some machines), the application calls this function. Additionally, the database can initiate a break to the client if an abnormal operation occurs, such as during an attempt to load a row of invalid data using SQL*Loader.

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.

SQL*Net and the Network Listener

TNS includes a protocol-independent application listener that receives connections on behalf of any TNS application, over any underlying protocol. Referred to as a network listener, it runs as a single process or task and can service the needs of all TNS applications over all protocols available on a machine.

SQL*Net version 2, as a TNS-based product, uses the network listener on a server to receive incoming connections from SQL*Net clients. The network listener listens for SQL*Net connections on a specific port or socket, which is defined in the ADDRESS portion of the connect descriptor. A service may have more than one listener if needed. For more information about using multiple listeners for a database server, see "Listener Load Balancing" later in this chapter.

Network Listener and Native Listeners

The network listener is available for all standard transport protocols supported by TNS. In addition, there are protocols that have application generic listeners or connection acceptance methods, such as DECnet and APPC/LU6.2, that may receive TNS connections.

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.

Prestarted Dedicated Server Processes

SQL*Net release 2.1 and later provides the option of automatically creating dedicated server processes. With this option, when the listener starts, it creates Oracle server processes which are then available to service incoming connection requests. These processes may last for the life of the listener, and they can be reused by subsequent connection requests.

Note: Prestarted dedicated servers require SQL*Net release 2.1 or later, and require 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 - 3 shows the role of the network listener in a SQL*Net connection to a server connected to two communities.

Figure 2 - 3. Network Listener in a SQL*Net Connection

The steps involved in establishing a connection (as shown in Figure 2 - 3) 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.


Contents Glossary Index Home Previous Next