Figure 1: ActiveXperts Network Monitor Oracle Check - Download ActiveXperts Network Monitor now »
ActiveXperts Network Monitor uses SQL*Net to monitor Oracle servers for availability. The role of SQL*Net is to establish and maintain a connection between the client application and the server and exchange messages between them. SQL*Net is a software layer that is required to communicate between Oracle clients and servers. It provides both client-server and server-server communications across any network. It enables client tools to access, modify, share, and store data on Oracle servers over a Network. The communication between client applications and servers takes place across one or more networks, and is referred to as client/server communication.
ActiveXperts Network Monitor has two SQL*Net based checks for Oracle:
A Database-Oracle TNSPing check takes the following parameters:
A Database-Oracle Logon/Logoff check takes the following parameters:
SQL*Net 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, you can take advantage of all the features of the Oracle Server. This chapter provides an overview of SQL*Net by discussing:
SQL*Net provides the basis for two complementary means of distributed communications over a network: client-server and server-server computing.
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 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.
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.
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.
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.
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.
With SQL*Net, 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.
In a server-server configuration, this same heterogeneous network capability is extended to include database-to-database communications for distributed queries and updates in Oracle. Two types of server-server connections are possible using SQL*Net:
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, "Using SQL*Net". Also refer to Oracle 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, 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.
SQL*Net provides a number of diagnostic tools. The diagnostic tools include the following:
These tools are discussed in detail in the Oracle Network Products Troubleshooting Guide.
Oracle Network Manager 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 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 SQL*Net, Oracle Names 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.
Oracle SNMP support is provided in SQL*Net for the listener, Oracle 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, Oracle 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, Oracle 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 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.
The Oracle MultiProtocol Interchange works with SQL*Net 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, it is mentioned frequently in this manual as well. The MultiProtocol Interchange is configured using Oracle Network Manager.
Oracle Advanced Networking Option is an optional product that works with SQL*Net. 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.
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. 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 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 Oracle 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 Oracle Server, Developer 2000 tools, and any other Oracle or third-party product that supports SQL*Net.
Oracle DCE Integration works with SQL*Net 2.1.6 and later. It enables users to transparently use Oracle tools and applications to access Oracle 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 Oracle 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 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.