Introduction to SQL*Net
SQL*Net release 2.3.3 is Oracle Corporation's latest remote data access software. It enables both client-server and server-server communications across any network. With SQL*Net, databases and their applications can reside on different computers and communicate as peer applications. Using SQL*Net release 2.3, you can take advantage of all the features of the Oracle Server.
This chapter provides an overview of SQL*Net version 2 and later by discussing:
Functions of SQL*Net Version 2
SQL*Net version 2 provides the basis for two complementary means of distributed communications over a network: client-server and server-server computing.
Distributed Processing
In distributed or cooperative processing, clients and servers interact to resolve a single data transaction, even if the applications and databases are separate logical entities, even on separate physical machines. The transaction is distributed between the locations of the client and servers, and the client and servers must cooperate to complete the transaction.
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.
SQL*Net in Distributed Processing
SQL*Net is responsible for enabling communications between the cooperating partners in a distributed transaction, either client-server or server-server. Specifically, SQL*Net enables clients and servers to connect to each other, send data such as SQL statements and data responses, initiate interrupts from the client or server, and disconnect when the session is complete. During the life of the connection, SQL*Net resolves all differences between the internal data representations and/or character sets of the computers being used.
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
SQL*Net Functional Benefits
SQL*Net version 2 provides the following benefits to users of networked applications:
Network Transparency
Oracle applications developed with a local database can be distributed across a network to access the same, or a similarly formatted, Oracle database with no changes to the application. SQL*Net is responsible for forwarding application requests for data from an Oracle client or server to a server and returning the results to the initiator of the query. From the application developer's or application user's perspective, all data interaction using SQL*Net is invisible to the user or the application. Additionally, it is possible to change the network structure beneath the application without changing the application. This quality of being invisible is known as network transparency.
Protocol Independence
SQL*Net provides protocol independence to its applications. An application using SQL*Net can run over any network protocol. Any application built on any computer running any protocol can be distributed without change to other computers running other protocols.
Media/Topology Independence
When SQL*Net passes control of a connection to the underlying protocol, all media and/or topologies supported by that network protocol on that platform are indirectly inherited by SQL*Net. SQL*Net allows the network protocol to use any means of data transmission, such as Ethernet, Token Ring, FDDI, or SDLC, to accomplish the low-level data link transmission between the two computers.
Heterogeneous Networking
Oracle's client-server and server-server models provide the capability for connectivity across multiple network protocols, each in a manner appropriate to its function.
Client-Server Configuration
With SQL*Net Version 2, the client and server can belong to different communities connected by one or more MultiProtocol Interchanges. (For information on the MultiProtocol Interchange, see "MultiProtocol Interchange" later in this chapter and refer to the Oracle MultiProtocol Interchange Administrator's Guide). A community is a group of computers that can communicate using the same transport level protocol, such as TCP/IP; that is, computers that share a common protocol are said to be members of the same community. Using an Interchange as an intermediary, applications on the client and server machines can communicate in spite of having no common transport protocol. Any data exchanged in the client-server applications is forwarded through the Interchanges along the path.
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
Server-Server Configuration
In a server-server configuration, this same heterogeneous network capability is extended to include database-to-database communications for distributed queries and updates in Oracle7. Two types of server-server connections are possible using SQL*Net V2:
- a direct connection between two servers in the same community
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.
Location Transparency
The Oracle server provides the means to make data objects such as tables in remote databases look like they are in the local database to an application developer or user of that data object. The database link and synonym database features allow the database in which they are created to identify a remote data object and make the location transparent.
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.
Diagnostic Tools
SQL*Net release 2.3 provides a number of diagnostic tools. The diagnostic tools include the following:
- Client Status Monitor and the SQLNET.ORA Editor
These tools are discussed in detail in the Oracle Network Products Troubleshooting Guide.
SQL*Net Release 2.3 and Other Oracle Network Products
SQL*Net release 2.3 is based on the Oracle Transparent Network Substrate (TNS) technology. It works closely with other TNS-based products to provide easy to administer, flexible, transparent communication between client and server applications. Please refer to Chapter 2, "SQL*Net Version 2 Architecture," for more information about TNS.
The following Oracle products are bundled with SQL*Net release 2.3.3:
- MultiProtocol Interchange
Oracle Advanced Networking Option is not bundled with SQL*Net release 2.3.3. It is an optional, extra-charge product that includes the following components:
- security, enhanced user authentication, and single sign-on features (formerly included in the Secure Network Services product)
- Oracle DCE Integration (formerly included in the SQL*Net/DCE product)
- Oracle Native Naming Adapters
Oracle Network Manager
Oracle Network Manager release 3.1 is a tool that enables you to create the configuration files needed by Oracle networking products. It includes a graphical user interface which enables you to view the network in a hierarchical, or "tree view," structure so you can see the relationships among the network services, or in a map view which shows the network services as they relate to the user's actual network. Also provided is a context-sensitive online help system and an online walkthrough that takes you through the basic steps of configuring a network.
Oracle Network Manager enables you to validate the network so you can ensure that the resulting configuration files are free of common syntax errors and contain all required information. For further information about Oracle Network Manager, including detailed instructions on how to use it to build a network, consult the Oracle Network Manager Administrator's Guide. Oracle Network Manager should be used only by network administrators, not individual users.
Oracle Names
Oracle Names is transparent naming software from Oracle Corporation. It stores network names and addresses so that network components can contact one another easily without regard to their physical locations or specific configurations on the network. Access to the names and addresses is through Names Servers on the network. Included with this release of SQL*Net, Oracle Names 2.0 includes a Dynamic Discovery Option (DDO), which enables servers to register themselves with well-known Name Servers. When this option is used, minimal configuration files are required. If your network uses a flat naming structure and has a limited number of servers, this option may be appropriate. Oracle Names and the Dynamic Discovery Option are described in detail in the Oracle Names Administrator's Guide. However, because they work so closely with SQL*Net they are discussed in this manual as well. If you do not use the Dynamic Discovery Option, you configure Oracle Names Servers by using Oracle Network Manager.
SNMP Support
Oracle SNMP support is provided in SQL*Net release 2.2 (and later) for the listener, Oracle7 Server, Oracle Names, and MultiProtocol Interchange. SNMP support allows a database to be remotely monitored by any SNMP-capable management software in a TCP/IP network. SNMP (the Simple Network Management Protocol) is a de facto standard underlying many popular network management systems such as Hewlett Packard's OpenView, Novell's Network Management System, IBM's NetView/6000, and Sun Solstice. It enables Oracle products such as the SQL*Net network listener, Oracle7 Server, MultiProtocol Interchange, and Oracle Names to be located, identified, and monitored by a management station running at one or more centrally located nodes.
For information on configuring SNMP support for the listener, Oracle7 Server, Oracle Names, and MultiProtocol Interchange, see the Oracle Network Manager Administrator's Guide and your Oracle platform-specific documentation. Also see Chapter 6, "Configuring SNMP Support," in this guide for a general overview of configuring SNMP support for Oracle services. For detailed information about SNMP Support and the information it provides, see the Oracle SNMP Support Reference Guide.
Oracle Protocol Adapters
Oracle Protocol Adapters enable SQL*Net to establish connections over specific protocols or networks. Each machine on a network requires at least one protocol adapter, and additional adapters may be required if you use multiple protocols in your network. For example, a machine connecting a TCP/IP network and an SPX/IPX network would require a protocol adapter for each network. Also, the same machine would likely be running a MultiProtocol Interchange to enable communication between the dissimilar networks.
On some platforms, a single Oracle Protocol Adapter can operate on hundreds of different network interface boards, which means that you can deploy applications in any networking environment, including Ethernet, Token-Ring, FDDI (Fiber Distributed Data Interface), ATM (Asynchronous Transfer Mode), and wireless.
MultiProtocol Interchange
The Oracle MultiProtocol Interchange works with SQL*Net Version 2 to provide transparent communication between disparate communities. The product is described in detail in the MultiProtocol Interchange Administrator's Guide. However, because it works so closely with SQL*Net Version 2, it is mentioned frequently in this manual as well. The MultiProtocol Interchange is configured using Oracle Network Manager.
Oracle Advanced Networking Option
Oracle Advanced Networking Option is an optional product that works with SQL*Net release 2.1.4 and later. It includes several components, including the security and authentication services formerly included in Secure Network Services and DCE support included in the SQL*Net/DCE product.
Security Services
The security services available through Oracle Advanced Networking Option enable SQL*Net and related products to use network data encryption and checksumming so that data cannot be read or altered. It protects data from unauthorized viewing by using the RSA Data Security RC4(tm) or the Data Encryption Standard (DES) encryption algorithm. To ensure that data has not been modified, deleted, or replayed during transmission, Oracle Advanced Networking Option optionally generates a cryptographically secure message digest and includes it with each packet sent across the network.
Oracle Advanced Networking Option is supported by the MultiProtocol Interchange which means that clients and servers using different protocols can securely transfer data across network protocol boundaries. For example, clients using LAN protocols such as NetWare (SPX/IPX) can securely share data with large servers using different protocols such as LU6.2, TCP/IP, or DECnet.
Oracle Advanced Networking Option version 2.3. includes support for enhanced user authentication services such as single sign-on servers based on Kerberos and SESAME as well as token authentication based on Security Dynamics, Inc. SecurID card. New with this release of Oracle Advanced Networking Option is the Oracle Biometric Security Service, which supports biometric authentication based on the Identix TouchNet II fingerprint scanner.
These authentication services enhance the existing security facilities of Oracle7 such as access control logon, roles, and auditing by providing reliable user identification. No changes to applications are required. Oracle Advanced Networking Option works over all protocols, operating systems, and name services.
These services are available to most products that implement SQL*Net, including the Oracle7 Server, Developer 2000 tools, and any other Oracle or third-party product that supports SQL*Net.
Oracle DCE Integration
Oracle DCE Integration works with SQL*Net 2.1.6 and later. It enables users to transparently use Oracle tools and applications to access Oracle7 Servers in a DCE environment. It provides authenticated RPC (Remote Procedure Call) as the transport mechanism, which enables multi-vendor interoperability. The DCE security service enables a user logged onto DCE to securely access any Oracle application without having to specify a username or password. This is sometimes referred to as "external authentication," formerly referred to as "OPS$ support".
Oracle DCE Integration also provides support for DCE Cell Directory Service (CDS), which allows Oracle7 services to be transparently accessed throughout the DCE environment. Users can connect to Oracle database servers in a DCE environment using familiar Oracle service names. Oracle service names can be managed from a central location with standard DCE tools. For information on configuring Oracle DCE Integration, see the Oracle Advanced Networking Option Administrator's Guide and your Oracle platform-specific documentation.
Oracle Native Naming Adapters
Oracle Native Naming Adapters enable network administrators to store Oracle service names in a native naming service already in use in their network environment. Services include Network Information Services (NIS), Distributed Computing Environment Cell Directory Service (DCE CDS), and Novell NetWare Directory Services (NDS). Using an Oracle Native Naming Adapter enables you to continue to use familiar directory services to maintain names of Oracle services. Network administrators can configure each client to use Oracle Names, TNSNAMES.ORA, or one of the native naming adapters such as NIS, to resolve Oracle service names to addresses.
For information on installing and configuring Oracle Native Naming Adapters, refer to your Oracle platform-specific documentation.
SQL*Net's New Features
Release 2.3 of SQL*Net provides a number of new features and enhancements over previous releases. These enhancements include features that
- make SQL*Net easier to configure and use
- provide increased troubleshooting capability
- make SQL*Net networks available to non-database applications.
Performance Improvements
With SQL*Net release 2.3 you can choose to have multiple listeners for a single database and multiple listeners listening for more than one equivalent database. Listener load balancing enables you to distribute connection requests for a database among a number of listeners. With connections distributed among a number of listeners, no single listener is likely to be overburdened, and connection time will be faster. You can also have a many-to-many relationship between listeners and equivalent database instances. For more information about listener load balancing, see Chapter 2.
Ease of Use Enhancements
A number of new features make setting up and maintaining a SQL*Net release 2.3 network easier.
If you create a new network using Oracle Names version 2 and the Dynamic Discovery Option, you may not need to use Oracle Network Manager to create a network definition or extensive configuration files. Even if you add Oracle Names 2.0 and the Dynamic Discovery Option to an existing network, you can reduce the number of configuration files needed and the amount of effort required to add new clients and servers to the network. This option is suitable if the network has a flat naming structure, a single transport protocol, and a limited number of servers. For further information, see Chapter 3 in this manual and the Oracle Names Administrator's Guide.
Through the Listener Control Utility (LSNRCTL) you can set a number of listener parameters using the SET command, or display the parameters using the SHOW command. You can also change the listener password using LSNRCTL. For further information, see Chapter 5 in this manual.
Troubleshooting Features
New diagnostic tools have been added to release 2.3 of SQL*Net.
The new Audit Trail feature can be valuable to a network or database administrator, or anyone responsible for monitoring user activity. This feature adds a block of text to existing listener log files every time a connection is attempted by a client. For further information, see Chapter 2 in the Oracle Network Products Troubleshooting Guide.
Trace Route (TrcRoute) is a new utility that allows administrators to discover what path or route a connection is taking from the client to the server. TrcRoute travels as a special type of connect packet. For more information about TrcRoute, see Chapter 5 in the Oracle Network Products Troubleshooting Guide.
Client registration enables you to provide information about a client that is included in the Audit Trail when the client makes service requests. This registration information is captured in the audit trail and can be loaded into database tables for tracking purposes. It may be useful in compiling usage or billing statistics.
The Client Status Monitor is a utility that provides a snapshot of the client's current configuration. Diagnosing connection problems and providing information to Oracle Customer Support are made easier using this tool. The Client Status Monitor also provides access to the SQLNET.ORA Editor, described earlier in this section. For more information about the Client Status Monitor, see Chapter 5 in this manual, and Chapter 4 in the Oracle Network Products Troubleshooting Guide.
Oracle Trace is a new, optional form of tracing that is available with this release. Oracle Trace is controlled through the Oracle Enterprise Manager. and configured through Oracle Network Manager. Oracle Trace provides a uniform method of tracing connections among objects throughout an Oracle network.
Note: With the release of Oracle8, Oracle Trace will replace network tracing.
For further information about Oracle Trace, see Appendix E in this guide. See also the Oracle Trace User's Guide.
Open API
The SQL*Net OPEN API enables developers to create non-database applications that make use of an existing SQL*Net network. Refer to Appendix D for further information.
