Net8(TM) Administrator's Guide
Release 8.0.3

A51576_01

Library

Product

Contents

Index

Prev Next

3
Planning Your Network

Net8 provides a variety of options to help you design and manage networks that are both flexible and easy to use. With Net8's enhanced manageability and scalability, you can develop a network to support a wide range of environments whether they be simple workgroups or large mission critical enterprises.

This chapter describes considerations for planning a network using Net8. It explains the relationships of the network products, and options for expanding and better managing your future network. It includes the following sections:

3.1 Planning Overview

Take the time to review and plan your network before you configure it. As you are planning your Oracle network, remember to keep future needs in mind as well as present requirements. Some of the more important decisions which you will need to make regarding your network include:

3.2 Defining Your Network Layout

The following checklist is provided to help you outline the main components of your network.

  1. Define from the outset what it is you hope to accomplish with your network.
  2. Research the functionality required by your client applications, then assess the resources that are available to meet those requirements.
  3. Determine which machines or nodes are best suited for client or server applications.
  4. Select a networking protocol which best suits your existing or future networking requirements. You may be able to choose a single transport level protocol that works well on all the components in your network. Protocol adapters are available for most of the major protocols on many platforms. Your network may also involve clients or servers operating over more than one protocol.
  5. If you decide to use multiple protocols on your network, determine which nodes are best suited to install Oracle Connection Manager. Your choice of nodes will be determined by the networking protocols you have chosen as well as the machine's capacity to handle anticipated traffic.

It helps sometimes to draw a picture of your network layout displaying the logical as well as physical relationships between networking components.

3.3 Organizing and Naming Network Components

When you name objects such as databases in a networked environment, you will need to ensure that they are unique within the network. There are two basic models for naming objects in a network:

3.3.1 Flat Naming Model

Flat naming models dictate that all names are unique within a single domain. The use of this type of naming model is useful if your network is small, and there is no duplication of names. Figure 3-1 depicts a typical flat naming structure using a single domain name .WORLD.

Figure 3-1 Flat Naming Model

In this environment, database service names will automatically be appended with a ".WORLD" extension (for example, PROD.WORLD, FLIGHTS.WORLD, and so forth).

3.3.2 Hierarchical Naming Model

Hierarchical naming models divide names into a hierarchical structure to allow for future growth or greater naming autonomy. This type of naming model is useful when you have a network with more than one database with the same name in different geographical regions. Figure 3-2 depicts a hierarchical structure of domains including the (ROOT) domain, ACME domain, US.ACME, EUROPE.ACME, and ROW.ACME (Rest of World) domains.

Figure 3-2 Hierarchical Naming Model

Notice in Figure 3-2 both WEATHER and HISTORY are repeated, but the global names remain unique (that is, HISTORY.ROW.ACME and HISTORY.EUROPE.ACME).

3.3.2.1 Domains

A domain is a logical group of machines and network services. Within each domain all names must be unique, but across domains they can be repeated.

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.

Note: Although they appear similar, the domains of an Oracle network are completely independent of Domain Name Service (DNS) name spaces. For convenience, you may choose to mirror the DNS conventions in your Oracle network.

3.3.2.2 Default Domains

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 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.

Figure 3-3 depicts a client with a default domain of EUROPE.ACME.COM. When it makes a request for the service name "WINE", the default domain name EUROPE.ACME.COM is appended to the requested name so that the name becomes WINE.EUROPE.ACME.COM.

Figure 3-3 Default Domains

For more information on domain names, refer to Oracle8 Server Concepts.

3.3.2.3 Multiple Domains

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.

3.3.2.4 Using Consistent Domain Names

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.

3.3.3 Using Regions to Decentralize Administrative Responsibilities

Most networks have one central point of administration, that is, one administrative region. A region is an administrative name space that defines a population of Names Servers. It is used to divide administrative responsibilities.

If you are using Oracle Names and your network is large or widely distributed geographically, you may choose to have several points of network administration. For example, if your enterprise-wide network includes both the United States and Europe, you might want to have administrative decisions about the network made locally.

To delegate administrative regions, you must use a hierarchical naming model with each administrative region controlling one or more different domains.

3.3.3.1 How Multiple Region Networks Are Organized

Networks with multiple administrative regions must have a root administrative region and delegated administrative regions.

Root Administrative Regions

The domain at the top of a hierarchy is known as the root domain. Similarly, the administrative region that encompasses the root domain is known as the root administrative region. The root defines the reference point within which the naming model and the administrative model function. The root administrative region provides a common thread among all delegated administrative regions in a hierarchical naming structure. The root administrative region requires:

Delegated Administrative Regions

Administrative regions can be "delegated" from the top of the hierarchy in any granularity down to the number of domains in the naming model. For example, a naming model 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 3-4 depicts a network with six domains and three administrative regions: the ROOT, and two delegated regions (DR1, DR2).

Figure 3-4 Delegated Administrative Regions

Delegated Administrative Regions Below Root

All administrative regions below the root are considered delegated administrative regions. Each delegated region must know:

3.4 Resolving Service Names

Once you have defined your network layout and named your components, you will need to decide how best to configure and manage your network implementation. One of the first and most important decisions that you will need to make is choosing a naming method.

3.4.1 Naming Methods

Naming refers to the method used by a client application to resolve a service name to a network address when attempting to connect to a database service. Net8 provides four naming methods:

Depending on the size and characteristics of your network, each method will have positive and negative implications for both how the network is configured and administered.

3.4.2 Host Naming

Host Naming refers to a new naming method which enables clients in a TCP/IP environment to resolve the actual name of the computer (called the "host name") on which the database resides to a network address. This is different from other naming methods which use a service name.

A host name adapter resolves the host name through an IP address translation mechanism such as Domain Name Services (DNS), Network Information Services (NIS), or a centrally maintained TCP/IP hosts file.

3.4.2.1 Establishing a Connection Using the Host Naming Option

The process for establishing a client session using the host naming option is as follows:

  1. The client initiates a connect request providing the hostname where the database resides.
  2. A host name adapter resolves the host name through an IP address translation mechanism such as Domain Name Services (DNS), Network Information Services (NIS), or a centrally maintained TCP/IP hosts file to retrieve the physical TCP address of the host name for the client.
  3. Net8 makes the connect request to the host address provided.
  4. A network listener receives the request and establishes a connection to the database it is servicing.
  5. The connection is accepted by the default server.

The host naming option requires minimal configuration. For more information, refer to Chapter 4, "Configuring Network Clients".

3.4.3 External Naming

External Naming refers to the method of resolving a service name to a network address by using a supported non-Oracle naming service. Oracle Native Naming Adapters resolve service names stored in customers' native (non-Oracle) naming services. They include:

Use the Oracle Installer to install Native Naming Adapters on the clients and servers in your network. Refer to Chapter 4 to configure clients to use them. Refer to Appendix D for additional information about configuring individual Native Naming Adapters.

3.4.3.1 Establishing a Connection Using the External Naming Option

The process for establishing a client session using the external naming option is as follows:

  1. The client initiates a connect request providing a service name.
  2. A native naming adapter forwards the request to a native naming system that resolves the service name to a network address. The address is returned to the client.
  3. Net8 makes the connect request to the address provided.
  4. A network listener receives the request and redirects it to the database it is servicing.
  5. The connection is accepted by the server.

For more information on configuring the external naming option, refer to Chapter 4, "Configuring Network Clients".

3.4.4 Centralized Naming using Oracle Names

Centralized Naming refers to the method of resolving a service name to a network address by using Oracle Names. Oracle Names uses Names Servers to store the names and addresses of all database services on a network. Clients wishing to connect to a server direct their connect requests to a Names Server. Names Servers resolve the service name to a network address and return that information to the client.

3.4.4.1 Establishing a Connection Using the Centralized Naming Option

The process for establishing a client session using the centralized naming option is as follows:

  1. The client initiates a connect request providing a service name.
  2. The connect request is forwarded to a Names Server where the service name is resolved to a network address. This address is returned to the client.
  3. Net8 makes the connect request to the address provided.
  4. A network listener receives the request and redirects it to the database it is servicing.
  5. The connection is accepted by the server.

For more information on configuring the centralized naming option, refer to Chapter 4, "Configuring Network Clients"; for more information on configuring Names Servers, refer to Chapter 5, "Configuring Network Services"

3.4.4.2 Oracle Names and Native Naming Adapters

Oracle Names can be used in conjunction with other proprietary or open naming services to provide cross-environment name resolution. For example, Oracle Native Naming Adapters for CDS/DCE, NIS or NDS could be installed on all clients and servers in an enterprise network already running Oracle Names to provide name resolution across multiple name services.

Since Oracle Names is a proprietary name service storing and resolving names and addresses for Oracle databases only, one names solution could be to store all your Oracle services in Oracle Names, and use a directory service such as DNS or X.500 as your global naming service.

3.4.5 Local Naming

Local naming refers to the method of resolving a service name to a network address by using information configured and stored on each individual client. This information is stored in a local names configuration file called TNSNAMES.ORA.

3.4.5.1 Establishing a Connection Using the Local Naming Option

The process for establishing a client session using the local naming option is as follows:

  1. The client initiates a connect request providing a service name.
  2. The service name is resolved to a network address stored in a local names configuration file called TNSNAMES.ORA.
  3. Net8 makes the connect request to the address provided.
  4. A network listener receives the request and directs it to the database it is servicing.
  5. The connection is accepted by the server.

For information on configuring the local naming option, refer to Chapter 4, "Configuring Network Clients".

3.4.6 Choosing a Naming Method

Table 3-1 summarizes the relative advantages and disadvantages of each naming method and provides recommendations for using them in your network.

Table 3-1 Naming Method Comparison
Naming Method   Advantages/Disadvantages   Recommended for:  

Host Naming  

  1. Requires minimal user configuration. The user may provide only the name of the host to establish a connection.
  2. Eliminates the need to create and maintain a local names configuration file (TNSNAMES.ORA).
  3. Eliminates the need to understand Oracle Names administration procedures.

Disadvantages: Available only if all of the following are true:

  • Your client and server are connecting using TCP/IP.
  • The hostname is resolved through an IP address translation mechanism such as Domain Name Services (DNS), Network Information Services (NIS), or a centrally maintained TCP/IP hosts file.
  • No Oracle Connection Manager features are requested.
 

Simple TCP/IP networks (with 10-20 databases) that meet the criteria listed.  

External Naming  

Allows administrators to load Oracle service names into their native name service using tools and utilities with which they are already familiar.  

Networks with existing name services.  

Centralized Naming  

  1. Centralizes network names and addresses in a single place, facilitating administration of name changes and updates. For example, whenever a change is made to an existing server or a new server is added to the network, the change is made only once on one Names Server. This eliminates the need for an administrator to make changes to what potentially could be hundreds or even thousands of clients.
  2. Resolves service names across networks running different protocols

Disadvantages: Oracle Names stores network names and addresses for Oracle services only.  

Large, complex networks (over 20 databases) that change on a frequent basis.  

Local Naming  

  1. Provides a relatively straightforward method for resolving service name addresses.
  2. Resolves service names across networks running different protocols.

Disadvantages: Requires local configuration of all service name and address changes.  

Simple distributed networks with a small number of services that change infrequently.  

3.5 Managing Connection Requests

Net8 establishes Oracle sessions with the help of a network listener. When a listener receives a connection request, it by default bequeaths the accepted request to a dedicated server process. If you expect your network to receive excessive connection traffic, you can use the network listener to manage these requests by redirecting them to either prestarted or prespawned dedicated server processes or dispatcher server processes. Table 3-2 summarizes the relative advantages of each process and provides recommendations for using them in your network.

Table 3-2 Existing Server Processes
Process   Advantages   Recommended for:  

Prestarted or prespawned dedicated server processes  

  1. Reduces connect time by eliminating the need to create a dedicated server process for each new connection request.
  2. Provides 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.
 

Networks where the Oracle shared or multi-threaded server is not supported, or where the creation of a new server process is slow and resource-intensive.  

Shared or dispatcher server processes  

  1. Utilizes network resources more efficiently than a dedicated server process, thus increasing the throughput and performance of your sessions.
  2. Enables you to minimize the memory and processing resources needed on the server side as the number of sessions to the database increases.
 

Networks where the Oracle shared or multi-threaded server is supported, or where the creation of a new server process is slow and resource-intensive.  

For more information on configuring your network listener to redirect connect requests to either prestarted or prespawned dedicated server processes or shared or dispatcher server processes, refer to Chapter 5, "Configuring Network Services".

3.6 Improving Network Performance

Net8 provides a variety of options to help you improve your network performance including the following:

3.6.1 Connection Pooling

Connection pooling is a resource utilization feature that allows you to maximize the number of physical network connections to a multi-threaded server. This is achieved by sharing or pooling a dispatcher's set of connections among multiple client processes. Figure 3-5 shows how connection pooling works.

Figure 3-5 Connection Pooling

By using a time-out mechanism to temporarily release transport connections that have been idle for a specified period of time, connection pooling makes these physical connections available for incoming clients, while still maintaining a logical session with the previous idle connection. When the idle client has more work to do, the physical connection is reestablished with the dispatcher.

Connection pooling is enabled by parameters in your server's INIT.ORA configuration file. For more information, refer to the Oracle8 Server Reference Guide.

3.6.2 Multiplexing

Multiplexing is a feature that is available through Oracle Connection Manager. It allows you to funnel or concentrate multiple client sessions over a single transport to a multi-threaded server. Like connection pooling, multiplexing optimizes network resources and increases the number of client-server sessions that are possible across a fixed number of physical server ports. Unlike connection pooling, multiplexing maintains the transport connection.

For more information about multiplexing, refer to Chapter 2, "Understanding Net8". For more information on configuring multiplexing, refer to Chapter 5, "Configuring Network Services".

3.6.3 Using Connection Pooling and Multiplexing

Table 3-3 summarizes the relative advantages with using connection pooling and multiplexing and provides recommendations for using them in your network.

Table 3-3 Connection Pooling and Multiplexing
Feature   Advantages   Recommended for:  

Connection Pooling  

  1. Limits the number of network resources used per process.
  2. Maximizes the number of client/server sessions over a limited number of physical connections.
  3. Optimizes resource utilization.
 

Networks where many clients run interactive "high idle/search time" applications such as messaging and OLAP.  

Multiplexing  

  1. Supports large client populations.
  2. Allows identification and monitoring of real users.
  3. Allows mid-tier applications to support additional services.
  4. Requires only a single transport for clients with multiple applications.
  5. Requires only a single network connection for database links.
 

Networks where "continuous" connectivity is required by data/connection-intensive applications, such as stock ticker applications.  

3.6.4 Load Balancing

Load balancing is a feature that takes advantage of the fact that you can have multiple listeners for a single database or for two or more equivalent databases. By balancing the number of sessions coming into the listeners, you can improve connection performance. This may be achieved in one of two ways:

3.6.4.1 Listener Load Balancing

The listener load balancing feature allows you to distribute multiple incoming client sessions among several listeners. This feature helps to ensure that no single listener is overburdened. Periodically, each of the service handlers sends its load information to each listener that it is registered with. Thus, each listener knows how busy each of the handlers is and redirects incoming sessions to the least busy of those handlers.

Listener load balancing cannot be used in the following situations:

Listener load balancing is configured by defining multiple listeners for each database. Multiple listeners may exist either on the same platform as the database, or on different nodes as is the case with multi-threaded servers. To enable multiple listeners for multi-threaded servers, add the following parameter to your server's INIT.ORA configuration file:

MTS_MULTIPLE_LISTENERS=TRUE

For more information, refer to the Oracle8 Server Administrator's Guide.

3.6.4.2 Randomizing Client Requests among Several Listeners

If more than one listener services a single database, a client will randomly choose between the listeners for its connect requests. This randomization allows all listeners to share the burden of servicing incoming connect requests.

To enable your clients to choose from listeners at random, you will need to configure the different listening addresses for each service name. For more information on configuring service name addresses, refer to Chapter 4, "Configuring Network Clients".

3.6.5 Optimizing Data Transfer by Adjusting the Session Data Unit (SDU) Size

Tuning your application to reduce the number of round trips across the network is the best way to improve your network performance. If this is done, it is also possible to optimize data transfer by adjusting the size of the session data unit (SDU).

The session data unit (SDU) is a buffer that Net8 uses to place data before transmitting across the network. Net8 sends the data in the buffer either when requested or when it is full. Table 3-4 outlines when modifying the size of the session data unit (SDU) may or may not be appropriate.

Table 3-4 Considerations for when to modify the size of the session data unit (SDU)
Modify session data unit size when:   Do not modify session data unit size when:  
  1. The data coming back from the server is fragmented into separate packets
  2. You are on a wide area network (WAN) that has long delays
  3. Your packet size is consistently the same
  4. Large amounts of data are returned
 
  1. Your application can be tuned to account for the delays
  2. You have a higher speed network where the effect of the data transmission is negligible
  3. Your requests return small amounts of data from the server
 

You may adjust the session data unit size by adding a parameter either in your local names configuration file (TNSNAMES.ORA), or in your listener configuration file (LISTENER.ORA). For more information, refer to Chapter 4, "Configuring Network Clients"and Chapter 5, "Configuring Network Services".

3.6.6 Persistent Buffer Flushing for TCP/IP

Under certain conditions in some applications using TCP/IP, Net8 packets may not get flushed immediately to the network. Most often, this behavior occurs when large amounts of data are streamed from one end to another. The implementation of TCP/IP itself is the reason for the lack of flushing, and can cause unacceptable delays. To remedy this problem, you can specify no delays in the buffer flushing process. For more information, refer to the section titled, Persistent Buffer Flushing for TCP/IP in Chapter 5, "Configuring Network Services".

3.6.7 Configuring Listener Queuesize

If you anticipate receiving a large number of connection requests for a listening process (such as a network listener, Oracle Connection Manager or Oracle Names) over TCP/IP, Net8 allows you to configure the listening queue to be higher than the system default. For more information, refer to Chapter 5, "Configuring Network Services".

3.7 Planning Summary

Table 3-5 summarizes many of the options you may have chosen as you planned your network.

Table 3-5 Network Summary
Subject   Options  

Network Layout  

  • Single or Multiple Protocols
 

Component Naming  

  • Flat or Hierarchical Naming Model
 

Service Name Resolution  

  • Host Naming
  • External Naming
  • Centralized Naming
  • Local Naming
 

Connection Request Management  

  • Dedicated Server Processes
  • Prestarted/Prespawned Dedicated Server Processes
  • Dispatcher Shared Server Processes
 

Network Performance  

  • Connection Pooling
  • Multiplexing
  • Listener Load Balancing
  • Optimizing the Session Data Unit Size
  • Persistent Buffer Flushing
  • Increasing the Listener Queue Size
 




Prev

Next
Oracle
Copyright © 1997 Oracle Corporation.

All Rights Reserved.

Library

Product

Contents

Index