SQL*Net Version 2 Architecture
SQL*Net version 2 uses the Transparent Network Substrate (TNS) and industry-standard network protocols to connect a client to a server and establish an Oracle session.
The next few sections provide a discussion of SQL*Net and the role it plays in distributed systems. The following architectural concepts are discussed:
- Transparent Network Substrate
- distributed processing with SQL*Net
- SQL*Net and the network listener
Transparent Network Substrate (TNS)
Forming the basis for Oracle networking products, the Transparent Network Substrate (TNS) enables Oracle to provide a network of applications above all existing networks of computers. With TNS, peer-to-peer application connectivity is possible where no direct machine-level connectivity exists.In peer-to-peer architecture, two or more nodes can communicate with each other directly, without the need for any intermediary devices. In a peer-to-peer system, a node can be both a client and a server.
TNS provides two key features to a TNS-based network product and, in turn, any application built using TNS:
- a single, common interface to all industry-standard protocols
- the ability to connect to applications in physically separate networks through one or more MultiProtocol Interchanges
TNS is the foundation component of all current and planned network products from Oracle. Today, TNS networks connect Oracle clients and servers through SQL*Net version 2. In the future, Oracle Corporation will provide additional TNS-based application connectivity tools.
SQL*Net's Communication Role
Communication between client and server proceeds in a stack-like fashion with corresponding levels communicating in a peer relationship. The logical exchange unit at each layer of the stack conveys the level of generalization employed at that level. The Oracle client and server exchange SQL statements and data rows. At the UPI/OPI (User/Oracle Program Interface) layers, these exchanges translate into series of calls to SQL routines such as logon, parse, execute, and fetch. In a distributed transaction, SQL*Net is responsible for sending information across various networks on behalf of a client application or database server. In such a configuration, there are commonly two types of computers acting as the client and server.
Two-Task Common ensures that all differences between clients and servers, such as internal datatype representations or NLS character sets, are resolved, allowing the client and server to communicate transparently. SQL*Net relays all communication tasks to TNS through its common entry points. SQL*Net is unaffected by the specific communication mechanism used underneath TNS (for example, TCP/IP, DECnet, shared memory, and so on). The SQL*Net layer handles these calls as a series of Oracle send/receive messages, and TNS in turn processes the packets over the network. The network protocol, not provided by Oracle (typically provided with each particular platform by its vendor), supplies a reliable means of communication between the two tasks.
Components Involved in Distributed Processing
Several software components are involved in completing a distributed transaction, whether it is a client-server or server-server transaction. Figure 2 - 1 shows the components of a client-server session. These components are described in the following sections.
Figure 2 - 1. Oracle Client-Server Components
Client-Side Interaction
The following paragraphs discuss the components of the client-server transaction process, beginning with the client application and concluding with the Oracle Server.
Client Application
The client application provides all user-oriented activities, such as character or graphical user display, screen control, data presentation, application flow, and other application specifics. The application identifies any SQL database operations to send to the server database and passes them through the User Program Interface (UPI).
User Program Interface (UPI)
The UPI code contains all information required to initiate a SQL dialogue between the client and the server. It defines calls to the server to:
- parse SQL statements for syntax validation
- open a cursor for the SQL statement
- bind client application variables into the server shared memory
- describe the contents of the fields being returned based on the values in the server's data dictionary
- execute SQL statements within the cursor memory space
- fetch one or more rows of data into the client application
The client application uses some combination of these calls to request activity within the server. Often, all UPI calls can be combined into a single message to the server, or they may be processed one at a time through multiple messages to the server, depending on the nature of the client application. Oracle products attempt to minimize the number of messages sent to the server by combining many UPI calls into a single message to the server. When a call is performed, control is passed to SQL*Net to establish the connection or transmit the request to the server.
Two-Task Common
Two-Task Common provides character set and data type conversion between different character sets or formats between client and server. This layer is optimized to perform conversion only when required on a per connection basis.
At the time of initial connection, SQL*Net version 2 is responsible for evaluating differences in internal data and character set representations and determining whether conversions are required for the two computers to communicate.
SQL*Net
The role of SQL*Net is to establish and maintain a connection between the client application and the server and exchange messages between them. The network listener receives connection requests for a particular database and passes control to the server.
Transparent Network Substrate (TNS)
TNS receives requests from network applications, in this case SQL*Net, and settles all generic machine-level connectivity issues, such as:
- the location of the server or destination (open, close functions)
- whether one or more MultiProtocol Interchanges will be involved in the connection (open, close functions)
- how to handle interrupts between client and server based on the capabilities of each (send, receive functions)
The generic set of TNS functions (open, close, send, receive) passes control to an Oracle Protocol Adapter to make a protocol-specific call.
Additionally, TNS optionally provides encryption and sequenced cryptographic message digests to protect data in transit. See the Oracle Advanced Networking Option Administrator's Guide for more information.
Oracle Protocol Adapter
The Oracle Protocol Adapters are responsible for mapping TNS functionality to industry-standard protocols used in the client-server connection. Each adapter is responsible for mapping the equivalent functions between TNS and a specific protocol.
Network-Specific Protocols
All Oracle software in the client-server connection process requires an existing network protocol stack to make the machine-level connection between the two machines. The network protocol is responsible only for getting the data from the client machine to the server machine, at which point the data is passed to the server-side Oracle Protocol Adapter.
Server-Side Interaction
Going up the process stack on the server side is the reverse of what occurred on the way down the client side. See the right side of Figure 2 - 1.
The one operation unique to the server side is the act of receiving the initial connection. The server has a process (the network listener) that regularly checks for incoming connections and evaluates their destination.
The network listener is a process on a server that listens for connection requests for one or more databases on one or more protocols. It is discussed in "SQL*Net and the Network Listener" 2 - 9. Based on the Oracle Server ID (SID) specified, the connection is passed to the Oracle Server.
The components above SQL*Net, the OPI and the Oracle Server, are different from those on the client side.
Oracle Program Interface (OPI)
The OPI has a complementary function to that of the UPI. It is responsible for responding to each of the possible messages sent by the UPI. For example, a UPI request to fetch 25 rows would have an OPI response to return the 25 rows once they have been fetched.
Oracle Server
The Oracle Server side of the connection is responsible for receiving dialog requests from the client UPI code and resolving SQL statements on behalf of the client application. Once received, a request is processed and the resulting data is passed to the OPI for responses to be formatted and returned to the client application.
Server-to-Server Interaction
When two servers are communicating to complete a distributed transaction, the process and dialogues are the same as in the client-server scenario, except that there is no client application. See Chapter 5, "Distributed Updates" in Oracle7 Server Distributed Systems, Volume I for more information. The server has its own version of UPI, called NPI. The NPI interface can perform all of the functions that the UPI does for clients, allowing a coordinating server to construct SQL requests for additional servers. Figure 2-2 shows a server-to-server connection and all associated layers.
Figure 2 - 2. Oracle Server-Server Components
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:
- disconnect from server (close)
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
- additional connection request
- abnormal connection termination
- timer-initiated disconnect
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:
- receive data synchronously
- receive data asynchronously
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:
- initiate a break over the TNS connection
- reset a connection for synchronization after a break
- test the condition of the connection for incoming break
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.
How SQL*Net Establishes Connections to a Prestarted Dedicated Server
Prestarted (commonly referred to as "prespawned") Oracle7 Servers are server processes that are prestarted by the listener before any incoming connection request. They improve the time it takes to establish a connection on servers where the multi-threaded server is not used or not supported on a given machine. Their use in a heavily loaded distributed system can be beneficial.
Set the following parameters using Oracle Network Manager. They control how the server is prespawned.
PRESPAWN_MAX The maximum number of prespawned servers the listener creates. This value should be a large number and at least the sum of the POOL_SIZE for each protocol.
POOL_SIZE
The number of unused prespawned server processes for the listener to maintain on the selected protocol. The number must be greater than zero, but no larger than the PRESPAWN_MAX value. Set this value to the average expected number of connections at any given time.
TIMEOUT
The time that an inactive server process should wait for the next connection before it shuts down. This parameter is used to prevent server processes from being immediately shut down after a client disconnects. For greatest efficiency, provide a short time value for this parameter.
You can set specific prespawned server parameters for each SID. Thus, systems with heavy use can be tailored to accommodate the larger number of connection requests by setting PRESPAWNED_MAX and POOL_SIZE to large values. Similarly, when systems require mostly shared connections, the number of prestarted servers can be set to a low value.
Following is the sequence of events that occur when you are using prestarted servers to service client connection requests:
1. The listener is started and listens on the addresses preconfigured in LISTENER.ORA, created by the network administrator using Network Manager.
2. The listener then spawns a series of server processes until it reaches the POOL_SIZE for each SID defined in LISTENER.ORA.
3. Each spawned server process performs a wildcard listen and provides the listener with the wildcard address that it is listening on. The listener initially marks all prestarted servers as idle.
4. The client calls the preconfigured well-known address of the listener.
5. The listener receives the connection request, performs the connection handshake and determines if the client is allowed to connect. If not, the listener refuses the connection and then resumes at step 9.
6. The listener issues a redirect message to the client containing one of the wildcard listen addresses of the prespawned servers. The listener then logs that server as active.
7. The client dissolves the connection to the listener and then establishes a connection to the prespawned server using the address provided in the redirect message.
8. The listener spawns another server to replace the active prespawned server (provided the PRESPAWN_MAX value is greater than the number of prespawned server processes active and idle).
9. The listener continues listening for incoming connections.
The above sequence of events continues until the PRESPAWN_MAX is reached, at which point the listener will cease spawning new servers.
When clients disconnect, the prespawned server associated with the client is returned to the idle pool. It then waits the length of time defined in the TIMEOUT parameter to be assigned to another client. If no client is handed to the prespawned server before TIMEOUT expires, the prespawned server shuts itself down.
See the Oracle Network Manager Administrator's Guide for more information on configuring this feature.
How SQL*Net Establishes Connections to a Multi-Threaded Server
The multi-threaded server enables many clients to connect to the same server without the need for dedicated server processes for each client. Using the multi-threaded server enables you to minimize the memory and processing resources needed on the server side as the number of connections to the database increases.
The sequence of events that occurs with the Oracle7 multi-threaded server is as follows:
- The listener and the multi-threaded server start up.
- Clients connect to the Oracle7 multi-threaded server.
What Happens When an MTS and Listener Are Started
During initial startup of the Oracle7 multi-threaded server and the listener, the following sequence occurs:
2. The DBA starts the Oracle7 database. Dispatchers start according to the configuration parameters in the initialization parameter file. Dispatchers each use one particular protocol. There may be many, on assorted protocols. Each dispatcher performs a wildcard listen for the protocol assigned to it.
Note: A wildcard listen is where the server process listens, but informs the underlying protocol stack (or operating system in the case of the IPC Protocol Adapter) that it has no preference as to what address it listens for other than specifying the protocol on which it wishes to perform the operation. As a result, many operating systems will choose a free listening address and automatically assign this to the requesting server process.
Note: If step 2 is performed before step 1, the dispatchers will be unable to contact the listener in step 3. If this occurs, each dispatcher loops and attempts to reconnect to the listener every 60 seconds. Meanwhile, incoming connection requests will be handled through other means (prespawned dedicated or newly spawned dedicated server processes).
The listener and the Oracle7 multi-threaded server should be ready for incoming connections at this point. You can check which dispatchers have registered with the listener by typing
lsnrctl services listener_name
How a Multi-Threaded Server Connection Request Is Handled
The following is how a multi-threaded server connection request is handled:
1. The client calls the address of the listener for the desired database. If there is more than one listener, the client randomizes its calls among them.
2. The listener receives the connection request, performs the connection handshake and determines if the client is allowed to connect (by checking the list of SIDs it listens for), at which point it continues with step 6. If not, the listener refuses the connection and then resumes at step 6.
3. The listener issues a redirect message back to the client containing the address of the least-called dispatcher that is listening on the protocol used by the client.
4. The client closes the connection to the listener and then establishes a new connection to the dispatcher, using the address provided by the listener in the redirect message.
5. The listener and dispatcher perform a short handshake to update each other of the presence of a new connection. This is so that the listener can load balance connections between dispatchers running on the same protocol.
6. The listener resumes listening for incoming connections.
When an Oracle7 Server has been configured as a multi-threaded server, incoming connections are always routed to the dispatcher unless the connection request specifically requests a dedicated server (by having SERVER=DEDICATED in the CONNECT_DATA portion of the connect descriptor) or no dispatchers are available. To create this parameter, create an alias for the database using Network Manager. (An alias is an alternative name that is mapped to a service name.) Use Network Manager to make that alias a dedicated server. See Chapter 5 in the Oracle Network Manager Administrator's Guide for more information.
Listener Load Balancing
The listener load balancing feature provides for the distribution of connections among listeners for Oracle7 Servers. By having connections distributed among a number of listeners, no single listener is likely to be overburdened, and connection time will be faster.
Note: You may have a many-to-many relationship between listeners and equivalent database instances.
Once randomly selected, the listeners behave as they have in previous releases, distributing connection requests to the dispatchers on the basis of their load (for multi-threaded servers) or to dedicated servers.
How Listener Load Balancing Works
There can be multiple listeners for a single database or multiple listeners for two or more equivalent databases.
Multiple Listeners for a Single Database
You can have more than one listener for a single database of any kind. The listeners for a dedicated server must be on the same node as the server. Listeners for a multi-threaded server can be distributed on different nodes; the dispatchers are able to register with listeners across nodes.
Suppose there were listeners on two different nodes that were listening for a single multi-threaded server, as shown in Figure 2 - 4.
Figure 2 - 4. Multiple Listeners for a Multi-Threaded Server
All dispatchers register with all the listeners listed in the database parameter file, and the client randomizes between the listeners. The listener passes the address of the least-used dispatcher to the client, and the client connects using that dispatcher.
Multiple Listeners for Equivalent Databases
If there is a set of databases configured to provide equivalent service (such as a replicated database) on the network, you can use listener load balancing among several listeners that all listen for more than one instance of the database. An example of this is shown in Figure 2 - 5.
Figure 2 - 5. Multiple Listeners for Equivalent Databases
In this figure, both listeners listen for two database instances. The client randomizes between the listeners. The listener passes the address of the least-used dispatcher to the client, regardless of whether the dispatcher is for Emp or HR, because they are virtually identical.
Note: Oracle Parallel Servers have their own method of listener load balancing. See your Oracle Parallel Server and platform-specific documentation on how to configure parallel servers. Use the listener load balancing method you prefer.
Listener load balancing may be particularly useful in replicated environments, where a particular group of users may have a schema that's the same across different databases, even though other things on the database may be different. In such a case, you could allow the users to update any of the replicas they happened to get connected to, and synchronize them later.
How Connections Are Made
The dispatcher for each multi-threaded server registers with all listeners designated in the MTS_LISTENER_ADDRESS parameters in the database parameter file. When a connection request is made, the client interface code randomizes among listeners within the same community. The listener redirects the client connection request to the least-used dispatcher, which connects the client to a shared server process.
Similarly, the clients that want to connect to a dedicated server randomize their connection requests among the listeners on the same protocol for that server, as listed in the TNSNAMES.ORA file, or stored in the Names Server cache. All listeners for a dedicated server must be on the same node. The randomly selected listener spawns a server process and hands off the incoming connection to the server.
Note: You cannot have listener load balancing with prestarted dedicated servers, because a prestarted dedicated server process registers only with the listener that started it.
Configuring Listener Load Balancing
For information about how to configure listener load balancing, see "Configuring Listener Load Balancing" in Appendix A.
