|Net8 Administrator's Guide
Part Number A76933-01
This chapter introduces Net8, and provides an overview of its main applications, features, and functionality. It contains the following sections:
Net8 Client enables client connections to databases across a network. A client-side application sends a request to Net8 to be transported across the network to the server.
Net8 Server enables the listener, through a protocol, to accept connections from client applications on the network.
Oracle supports the following protocols:
The Transmission Control Protocol/Internet Protocol (TCP/IP) is the de facto standard Ethernet protocol used for client/server conversation over a network. TCP/IP enables an Oracle application on a client to communicate with remote Oracle databases through TCP/IP (if the Oracle database is running on a host system that supports network communication using TCP/IP).
The TCP/IP with Secure Sockets Layer (SSL)protocol enables an Oracle application on a client to communicate with remote Oracle databases through TCP/IP and SSL (if the Oracle database is running on a host system that supports network communication using TCP/IP and SSL). Oracle Advanced Security is required in order to use TCP/IP with SSL.
SSL stores authentication data, such as certificates and private keys, in an Oracle Wallet. When the client initiates a Net8 connection to the server, SSL performs a handshake between the two (using the certificate). During the handshake the following processes occur:
The server checks the user's certificate to verify that it bears the certificate authority's signature.
The Sequenced Packet Exchange (SPX) protocol enables client/server conversation over a network using SPX/IPX. This combination of Oracle products enables an Oracle application on a client to communicate with remote Oracle databases through SPX/IPX (if the Oracle database is running on a host system that supports network communication using SPX/IPX). This protocol is predominantly used in Novell Netware environments.
The Named Pipes protocol is a high-level interface providing interprocess communications between clients and servers (distributed applications). One process (the server side of the application) creates the pipe, and the other process (the client side) opens it by name. What one side writes, the other can read, and vice versa. Named Pipes is specifically designed for PC LAN environments.
Named Pipes enables client/server conversation over a network using Named Pipes. This combination of Oracle products enables an Oracle application on a client to communicate with remote Oracle databases through Named Pipes (if the Oracle database is running on a host system that supports network communication using Named Pipes).
The Logical Unit Type 6.2 (LU6.2) protocol is part of the IBM Advanced Program-to-Program Communication (APPC) architecture.
APPC is the IBM peer-to-peer (program-to-program) protocol for a System Network Architecture (SNA) network. SNA is an IBM reference model similar to the Open Systems Interconnect (OSI) model of the International Standards Organization (ISO).
APPC architecture lets the client and host communicate over an SNA network without forcing the client to emulate a terminal (as in terminal-to-host protocols). APPC architecture enables peer-to-peer communication; the client can initiate communication with the server.
An SNA network with the LU6.2 and Physical Unit Type 2.1 (PU2.1) protocols provides APPC. The LU6.2 protocol defines a session between two application programs; LU6.2 is a product-independent LU-type.
LU6.2 enables an Oracle application on a PC to communicate with an Oracle database. This communication occurs over an SNA network with the Oracle database on a host system that supports APPC.
The Bequeath protocol enables clients that exist on the same machine as the server to retrieve information from the database without using the listener. The Bequeath protocol internally spawns a dedicated server process for each client applications. In a sense, it does the same operation that a remote network listener does for your connection, yet locally.
Bequeath is used for local connections where an Oracle client application, such as SQL*Plus, communicates with an Oracle server running on the same machine
Oracle Connection Manager is a router through which a client connection request may be sent either to its next hop or directly to the database server. Clients who route their connection requests through a Connection Manager can then take advantage of the connection concentration, Net8 access control, or multi-protocol support features configured on that Connection Manager.
Oracle Connection Manager listens for incoming requests from clients and initiates connect requests to destination services. Oracle Connection Manager performs these tasks with the help of two processes:
CMGW (Oracle Connection Manager Gateway Process)
A gateway process acting as a hub for Oracle Connection Manager. This process is responsible for the following:
CMADMIN (Oracle Connection Manager Administrative Process)
CMADMIN is a multi-threaded process that is responsible for all administrative issues of Oracle Connection Manager. This process is responsible for the following:
"Oracle Connection Manager Control Utility (CMCTL)" for information on using CMCTL
Oracle Connection Manager enables you to multiplex or funnel multiple client network sessions through a single transport protocol connection to a multi-threaded server destination.
Concentration reduces the demand on resources needed to maintain multiple connections between two processes by enabling the server to use fewer connection end points for incoming requests. This enables you to increase the total number of network sessions that a server can handle. By using multiple Connection Managers, it is possible for thousands of concurrent users to connect to a server.
Figure 4-1 shows how connection concentration works:
"Enabling Connection Concentration" for configuration information
Oracle Connection Manager also includes a feature which you can use to control client access to designated servers in a TCP/IP environment. By specifying certain filtering rules you may allow or restrict specific clients access to a server based on the following criteria:
Some firewall vendors also offer Net8 Firewall Proxy, which is installed on firewalls requiring an application proxy. Net8 Firewall Proxy has the same access control functionality as Oracle Connection Manager.
Oracle Connection Manager also provides multiple protocol support enabling a client and server with different networking protocols to communicate with each other. This feature replaces functionality previously provided by the Oracle Multi-Protocol Interchange with SQL*Net version 2.
Net8 can traverse as many networking protocol stacks as can be installed and supported. In fact, the number of networking protocols supported is limited only by those restrictions imposed by the specific node's hardware, memory, and operating system.
Figure 4-2 depicts how a client in an SPX network can route its network session to a server over a TCP/IP transport through Oracle Connection Manager.
"Enabling Multi-Protocol Support" for configuration information
This section covers topics in the following sections:
Oracle Names establishes and maintains an integrated system of Oracle Names servers which work together like a directory service. The system stores addresses for all the services on a network and makes them available to clients wishing to make a connection.
Much like a caller who uses directory assistance to locate a telephone number, clients configured to use Oracle Names refer their connection requests to an Oracle Names server. The Oracle Names server attempts to resolve the service name provided by the client to a network address. If the Oracle Names server finds the network address, it then returns that information to the client. The client can then use that address to connect to the service.
Figure 4-3 depicts how Oracle Names works to help establish a connection between a client and server:
"Configuring the Oracle Names Method" for configuration information
Most networks have one central point of administration, that is, one administrative region. An administrative region consists of a collection of Oracle Names servers that administer services in a network. All connect information is stored in a single data repository, which has the authority to interpret a service name. All Oracle Names servers within an administrative region query information from this data repository. If the administrative region uses a database for storage, there is one database per administrative region. There can be any number of Oracle Names servers. Oracle Names provides support for one or more administrative regions.
Most enterprise environments with multiple data centers and many Oracle instances will probably choose to take advantage of multiple administrative regions. This enables each data center to independently define and manage the services in its own environment. At the same time, all service addresses are continuously available to all of the clients in the whole environment. Oracle Names servers transparently forward name resolution requests from clients in foreign administrative regions to the proper Oracle Names server.
An administrative region contains one or more domains used to divide administrative responsibilities.
Network domains are similar to file directories used by many operating systems in that they are hierarchical. Unlike file systems however, network domains may or may not correspond to any physical arrangement of databases or other objects in a network. They are simply names spaces developed to prevent name space conflicts.
Data in Oracle Names servers is updated through continuous replication between all the Oracle Names servers in the region, or by writing to and reading from a common Oracle database.
For smaller workgroup environments where all of the services are registered dynamically, administrators may configure Oracle Names servers to replicate data continuously among themselves. When a listener registers a new service, information about that service is immediately passed along to other Oracle Names servers in the administrative region.
Alternatively, administrators in large environments normally want to store their registration data in an Oracle database, called the region database. A region database consists of tables that store Oracle Names information. If the Oracle Names servers are configured to use an Oracle database as a repository, all service registrations are written to the database. Each Oracle Names server in a given administrative region periodically polls the region database for updated registrations. In this way, new registrations are communicated in a timely manner to all of the Oracle Names servers in a given administrative region. At the same time, it relieves Oracle Names servers of the necessity to communicate directly with each other, and it provides better reliability.
Below is a description of the types of data stored in an Oracle Names server.
Global database names and addresses
The Oracle Names server retrieves information about the database, including the global database name (database name and domain) and address, from the listener. The address is configured in the
Other Oracle Names server names and addresses
An Oracle Names server stores the names and addresses of all other Oracle Names servers in the same administrative region. If there is more than one administrative region in a network, the Oracle Names server stores the name and address of at least one Oracle Names server in the root administrative region and each of the immediate sub-regions. You do not need to register this information.
Net service names
If you register net service names with the NAMESCTL control utility or Net8 Assistant, an Oracle Names server stores them. An Oracle Names server also stores gateways to non-Oracle databases and Oracle RDB databases.
Global database links
Database links allow a database to communicate with another database. The name of a database link is the same as the global database name of the database to which the link points. Typically, only one database link should exist per database.
The following types of database links can be created:
Because Oracle Names retrieves the global database name from the listener, a global database link that is the global database name is automatically registered with the Oracle Names server. Therefore, you do not need to register this information.
User name and password credentials for the global database link may be registered with the Oracle Names server using Net8 Assistant.These global database links may be supplemented with link qualifiers defined through the Net8 Assistant.
See Also: Oracle8i Distributed Database Systems
An Oracle Names server stores aliases or alternative service names for any defined net service name, database service, or global database link. Aliases may be registered with the Oracle Names server using either the NAMESCTL control utility or Net8 Assistant.
Oracle Connection Managers
An Oracle Names server stores the names and listening addresses of all Oracle Connection Managers on the network. You do not need to register this information.
When you use Oracle Names, objects such as databases in a networked environment need to be named in a way as to ensure that they are unique within the network. There are two basic models for naming objects in a network:
The use of the single domain naming model is useful if your network is small, and there is no duplication of names. Figure 4-4 depicts a typical flat naming structure using a single domain name, .WORLD.
In this environment, database service names are automatically appended with a .WORLD extension (for example, PROD.WORLD, FLIGHTS.WORLD, and so forth).
Hierarchical naming models divide names into a hierarchical structure to allow for future growth or greater naming autonomy. This type of naming model enables more than one database with the same simple name in different domains.
Figure 4-5 depicts a hierarchical structure of domains including the (ROOT) domain, ACME domain, US.ACME, EUROPE.ACME, and ROW.ACME (Rest of World) domains.
Notice in Figure 4-5 both WEATHER and HISTORY are repeated, but the names remain unique (that is, HISTORY.ROW.ACME and HISTORY.EUROPE.ACME).
The default domain is the domain within which most of the client's name requests are conducted. This is usually the domain in which the client resides, though it could also be another domain from which the client most often requests services. A client can request a network service within its default domain using the service's simple, unqualified name, that is, without specifying a domain name. If a user requests a name without a "." character in it, the default domain name is automatically appended to the database service or database link name requested.
For example, a client is configured with a default domain of EUROPE.ACME.COM. When it makes a request for the service name "WINE" in Figure 4-5, the default domain name EUROPE.ACME.COM is appended to the requested name so that the name becomes WINE.EUROPE.ACME.COM.
Multiple domains are related hierarchically to a root domain (the highest-level domain in the hierarchy) in a series of parent-child relationships. For example, under the root might be several domains, one of which is called COM. Under the COM domain might be several more domains, one of which is ACME. Under the ACME domain might be several domains, such as US, EUROPE, and so forth.
In previous releases of SQL*Net and Oracle Names, a network with only one domain would by default be called ".world". This is no longer a requirement with Net8 and Oracle Names version 8. You may, however, want to keep the same convention to be backward compatible, as well as to avoid having to rename all your databases.
If you are using Oracle Names and your network is large or widely distributed geographically, you may choose to have multiple administrative regions. For example, if your network includes both the United States and Europe, you might want to have administrative decisions about the network made locally. To subdivide, you must delegate regions and domains from a parent to a child or subregion.
To delegate administrative regions, you must use a hierarchical naming model with each administrative region controlling one or more different domains.
Administrative regions can be delegated from the top of the hierarchy down to other domains in the naming model. For example, a network with ten domains can have between one and ten administrative regions.
All administrative regions other than the root are hierarchically delegated directly or indirectly from it.
Figure 4-6 depicts a network with five domains and three administrative regions: the root, ACME, and two delegated regions (ROW, ASIA).
All administrative regions below the root are considered delegated administrative regions. Delegated administrative regions receive administrative responsibilities for a domain from other regions, such a the root administrative region. A delegated administrative region contains the following information:
There are significant differences between this version of Oracle Names and earlier versions:
In Oracle Names version 1, administrators configured Oracle Names servers using Oracle Network Manager and stored all topology data in a database. All the Oracle Names servers in a region shared the same information because they accessed the same database.
The clients had a list of preferred Oracle Names servers specified in the
sqlnet.ora file. This list was created by the user, listing the order of preferred Oracle Names to contact. The first Oracle Names server in the list would be contacted first by a client.
Preferred Oracle Names servers may still be configured.
"Configuring Preferred Oracle Names Servers" for configuration information
In Oracle Names version 2, the administrator could choose between continuing Oracle Names Server configuration as in version 1, or using the Dynamic Discovery Option. The Dynamic Discovery Option was recommended only for a network with a single region and single DNS domain. The Dynamic Discovery Option uses well-known Oracle Names servers, which are precise names hard-coded into DNS or the
hosts file on both the Oracle Names Server and its clients:
|The well-known host names for TCP connections||The well-known computer Names for Named Pipes connections1||The well-known service name for an SPX connection|
Well-known Names Server names for Named Pipes must be in all uppercase.|
Oracle Names servers then become available at these well-known addresses, so that clients do not need to be told, by way of a preferred Oracle Names server list, where to find an Oracle Names server.
If the Dynamic Discovery Option was chosen, each Oracle Names server automatically replicated its data to all other well-known Oracle Names servers in the administrative region. Listeners were configured to register themselves with well-known Oracle Names servers.
In Oracle Names version 8, the administrator may choose between continuing Oracle Names Server configuration as in version 1 or version 2, or using the new functionality. Oracle Names version 8 incorporates version 2 Dynamic Discovery Option features without the constraints of a single region and single domain. The main features of Oracle Names version 8 include:
A list of Oracle Names servers is created that enables a client or another Oracle Names server to contact an Oracle Names server. The process of creating the list is called discovery.
When a client tries to discover an Oracle Names server with the NAMESCTL utility or Net8 Assistant, one Oracle Names server is found first. Once the client finds an Oracle Names server, it pings all other Oracle Names servers in the region. A list of Oracle Names servers is then created on the client and saved to
.sdns.ora on UNIX and
sdns.ora on Windows platforms. This list is sorted in order of response time.
Discovery searches for the first Oracle Names server in the following order:
If the client is unable to find the first Oracle Names using the above methods:
Net8 offers the external naming methods:
NDS external naming enables you to use external NDS naming conventions to connect to an Oracle database on a Novell NDS-enabled network.
Organizations and corporations already using Network Information Service (NIS) as part of their system infrastructure have the option to store Oracle service aliases and addresses in NIS, using NIS External Naming.
CDS external naming enables you to transparently use Oracle tools and applications to access Oracle8i databases in a Distributed Computing Environment (DCE) environment.
"Configuring External Naming Methods" for NDS and NIS configuration information
Net8 offers the following authentication methods:
Enables a client single login access to an Windows NT server and an Oracle database.
Enables a client single login access to a multi-server and multi-database network under a single Novell Directory Services (NDS) directory tree.
Other authentication methods are available with Oracle Advanced Security, as described in "Single Sign-On".
This Oracle network data encryption and checksumming service ensures secure transmission of data over networks. Network Security uses encryption and checksumming engines from RSA Data Security, Incorporated.
The following algorithms are supported:
Single sign-on enables users to access multiple accounts and applications with a single password. This feature eliminates the need for multiple passwords for users and simplifies management of user accounts and passwords for system administrators.
Centralized, secure authentication services allow you to have high confidence in the identity of users, clients, and servers in distributed environments. Network authentication services can also provide the benefit of single sign-on for users.
The following authentication methods are supported:
Distributed Computing Environment (DCE) Integration enables users to transparently use Oracle tools and applications to access Oracle8i databases in a DCE environment. The Oracle DCE Integration product consists of two major components:
This section introduces the administration tools available with Net8. These tools include:
Net8 Configuration Assistant runs automatically after software installation. as described in your Oracle installation guide. It can be used on either the client or server.
It may be also be run in stand-alone mode to configure naming methods usage, the listener, net service names in the
tnsnames.ora file, and directory server access.
To start Net8 Configuration Assistant:
Net8 Assistant is a graphical user interface tool that combines configuration abilities with component control to provide an integrated environment for configuring and managing Net8. It can be used on either the client or server.
You can use Net8 Assistant to configure the following network components:
tnsnames.orafiles, centralized LDAP-compliant directory service, or an Oracle Names server.
If an Oracle Names server is configured, you start, stop, tune, or gather statistics for it with Net8 Assistant.
To start Net8 Assistant:
Net8 provides control utilities to control listeners, Oracle Names servers, and Oracle Connection Managers. These utilities include:
The Listener Control Utility (LSNRCTL) manages the listener. The general syntax of the LSNRCTL is as follows:
where listener_name is the name of the listener defined in the
listener.ora file. It is not necessary to identify the listener if you are using the default listener, named LISTENER.
LSNRCTL contains several types of commands:
The Oracle Connection Manager Control Utility (CMCTL) is a tool that you run from the operating system prompt to start and control Oracle Connection Manager. The general syntax of CMCTL is as follows:
where process_type is the name of the process that the command is being executed on. The choices are:
cman(both CMGW gateway and CMADMIN administrative processes)
adm(only the CMADMIN process)
cm(only the CMGW process)
The CMCTL utility contains several types of commands:
The Oracle Names Control Utility (NAMESCTL) is a tool that you run from the operating system prompt to start and control Oracle Names servers. The general syntax of the NAMESCTL is as follows:
NAMESCTL contains several types of commands: