Distributed processing allows the appropriate resources to be allocated from the appropriate machines on the network. The client, for example, can run on a user-friendly graphical workstation or desktop computer while the server resides on a machine more suited for efficient data processing. Distributed processing also allows data processing to be centralized so that many client applications can concurrently access a single server.
When a client or server makes a connection request, SQL*Net receives the request and, if more than one machine is involved, passes the request to its underlying layer, the transparent network substrate (TNS), to be transmitted over the appropriate communications protocol to the appropriate server. On the server, SQL*Net receives the request from TNS and passes it to the database as a network message with one or more parameters (that is, a SQL statement).
With the exception of the initial connection, both the local and remote applications generate the same requests whether they run on the same computer or are distributed across multiple computers. The initial connection differs only in that the name of the remote database must be specified by the application or user.
Figure 1 - 1 shows a local application (on the left), contrasted with a client-server application (on the right). In each case, the application is a SQL*Forms data entry screen.
Figure 1 - 1. Local and Distributed Processing
Figure 1 - 2 shows a connection between a client and a server running different protocols in adjacent communities. A MultiProtocol Interchange joins the two networks. SQL*Net and an Oracle Protocol Adapter specific to Protocol A are installed on the client, while SQL*Net and an Oracle Protocol Adapter specific to Protocol B are installed on the database server. The Interchange has adapters for both Protocol A and Protocol B.
Figure 1 - 2. Heterogeneous Networking with a client-server Connection
The example in Figure 1 - 3 shows both types of connections. In this example, Server 1 is a member of two communities, Community A and Community B. A client application in Community A accesses the database server (Server 1) in the same community. Server 1 determines that the transaction must be distributed further to retrieve data from tables in Server 2 and Server 3. Server 1 initiates a connection to Server 2 in Community B to which Server 1 also belongs. Server 1 also initiates a connection to Server 3 through the Interchange installed between Community B and Community C.
Figure 1 - 3. Heterogeneous Networking in a Distributed Database Transaction
Server 1 does not have to use an Interchange to initiate an additional request for data from Community B since it belongs to both Community A and Community B, but it has to use an Interchange to access a server in Community C.
Note that using the Interchange imposes no new restrictions on a SQL*Net connection. If the MultiProtocol Interchange is used in a client-server connection, clients have a standard peer-to-peer connection to the server despite the fact that they are in different communities. Similarly, if a server initiates a connection with another server through an Interchange using a database link, the standard database link restrictions apply.
This location transparency removes all references to the location of the data from applications when the synonym is used. Should the location of the remote table move to another machine or database, only the synonym and database link need to be updated to reference the new location; no applications changes are required. (Database links and synonyms are discussed further![[*]](jump.gif)
, "Using SQL*Net". Also refer to Oracle7 Server Distributed Systems, Volume I.)
Moreover, if the database link connection is specified as a service name (or symbolic name) in the configuration file (TNSNAMES.ORA), the database links accessing the data do not have to be changed if the remote database is moved; the only update required is to the TNSNAMES.ORA file. Similarly, if Oracle Names or an Oracle Native Naming Adapter is used, only the central network definition needs to be changed.
The network definition, TNSNAMES.ORA, and other configuration files are created using Oracle Network Manager. The configuration files are described in Appendix A, "Contents of the Configuration Files". For detailed instructions on creating the network definition and the configuration files for SQL*Net and other Oracle networking products, see the Oracle Network Manager Administrator's Guide
Note: If you have a network in which all clients and servers use SQL*Net release 2.3, and you use Oracle Names and its Dynamic Discovery Option, minimal configuration files are necessary and you may not need to create a network definition or to use Oracle Network Manager.