2
Net8 Concepts

This chapter provides an overview of how clients use Net8 in connections to servers. This chapter includes the following sections:

• Networking Environments

• Connect Operations

• Exception Operations

• Net8 Connection Models

• Client Connection Options

• Service Registration to the Listener

• Connection Load Balancing

• Database Identification by Service Name Rather than SID

• Service Resolution through Naming Methods

• Net8 and an LDAP-Compliant Directory Server

Networking Environments

Oracle networking environments are based on two concepts:

• Distributed Processing

• Distributed Databases

Distributed Processing

Oracle databases and client applications operate in what is known as a distributed processing environment. Distributed or cooperative processing involves interaction between two or more computers to complete a single data transaction. Applications, such as an Oracle tool, act as clients requesting data to accomplish a specific operation. Database servers store and provide the data.

In a typical network configuration, clients and servers may exist as separate logical entities on separate physical machines. This configuration enables for a division of labor where resources are allocated efficiently between a client workstation and the server machine. Clients normally reside on desktop computers with just enough memory to execute user friendly applications, while a server has more memory, disk storage, and processing power to execute and administer the database.

Distributed Databases

This type of client-server architecture also enables you to distribute databases across a network. A distributed database is a network of databases stored on multiple computers that appears to the user as a single logical database. Distributed database servers are connected by a database link, or path from one database to another. One server uses a database link to query and modify information on a second server as needed, thereby acting as a client to the second server.

Connect Operations

Net8 supports two types of connect operations:

• Connecting to Servers

• Disconnecting from Servers

Connecting to Servers

Users initiate a connect request by passing a user name and password along with an identifier for the service to which they want to connect. The identifier, called a connect identifier, identifies the following:

• The destination service, and

• The path, or network route access to that service

A connect identifier is specified in several different ways. One of the most common ways is through use of a net service name, another name for the service, which maps to a connect descriptor. A connect descriptor contains destination service and network route information. The destination service is indicated by using its service name for Oracle8i databases or its Oracle System Identifier (SID) for Oracle8 release 8.0 or Oracle7 databases. The network route provides, at a minimum, the location of the listener through use of a network address.

Shown here is a net service name called sales mapped to a connect descriptor:

sales= 
(description= 
  (address=(protocol=tcp)(host=sales-server)(port=1521))
  (connect_data=
    (service_name=sales.us.acme.com))

The listener, located on sales-server, listens with the TCP/IP protocol on port 
1521 for connection requests for a database service called sales.us.acme.com. 

Clients can use the complete connect descriptor or the connect identifier in a connect string. The following examples demonstrate one connect string that uses a complete connect descriptor and another connect string that uses the sales net service name.

CONNECT 
scott/tiger@(description=(address=(protocol=tcp)(host=sales-server1)(port=1521))
(connect_data=(service_name=sales.us.acme.com))


CONNECT scott/tiger@sales

When a net service name is used, connection processing takes place by first mapping sales to the connect descriptor. The connect descriptor is used to locate the listener and is then passed to the listener to locate the database. It is the job of the listener to determine what kind of service handler can best service the client's request. A service handler can be a multi-threaded server dispatcher, dedicated server, or prespawned dedicated server.

See Also: "Database Identification by Service Name Rather than SID" for an overview of service name and SID "Net8 Connection Models" for information about service handlers

Figure 2-1 shows the role of the listener in a typical Net8 connection.

Figure 2-1 Listener In a Typical Net8 Connection

Based on configuration, the listener performs one of the following actions:

• Hands the request directly off to a dispatcher

• Sends a redirect message back to the client with the location of the dispatcher or dedicated server process. The client then connects to the dispatcher or dedicated server process.

• Spawns a dedicated server process and passes the client connection to the dedicated server process.

Disconnecting from Servers

Requests to disconnect from the server can be initiated as described in the following sections:

• User Initiated Disconnect

• Additional Connection Request

• Abnormal Connection Termination

• Timer Initiated Disconnect or Dead Connection Detection

User Initiated Disconnect

A user can request a disconnection from the server when a client-server transaction completes. A server can also disconnect from a second server when all server-server data transfers have been completed and no need for the link remains.

Additional Connection Request

If a client application is connected to a server and requires access to another user account on the same or on another server, most Oracle tools first disconnect the application from the server to which it is currently connected. Once the disconnection is completed, a connection request to the new user account on the appropriate server is initiated.

Abnormal Connection Termination

Other components occasionally disconnect or abort communications without notifying Net8. In this event, Net8 recognizes the failure during its next data operation, and cleans up client and server operations, effectively disconnecting the current operation.

Timer Initiated Disconnect or Dead Connection Detection

Timer initiated disconnect, or dead connection detection enables Net8 to identify connections that have been left hanging by the abnormal termination of a client. This feature minimizes the waste of resources by connections that are no longer valid. It also automatically forces a database rollback of uncommitted transactions and locks held by the user of the broken connection.

On a connection with dead connection detection enabled, a small probe packet is sent from server to client at a user-defined interval (usually several minutes). If the connection is invalid, the send operation generates an error and the server process terminates the connection.

Exception Operations

Net8 supports three types of exception operations:

• Initiate a break over the connection

• Reset a connection for synchronization after a break

• Test the condition of the connection for incoming break

The user controls only one of these three operations, that is, the initiation of a break. When the user presses the Interrupt key (Ctrl-C on some machines), the application calls this operation. Additionally, the database can initiate a break to the client if an abnormal operation occurs, such as during an attempt to load a row of invalid data using SQL*Loader.

Net8 Connection Models

Connections between clients and servers are established using two different models:

• Multi-Threaded Server Model--The listener passes the connection to the dispatcher or redirects the clients to connect through a dispatcher.

• Dedicated Server Model--The listener starts a dedicated server and passes the connection to the dedicated server or redirects the clients to the dedicated server.

Multi-Threaded Server Model

In a multi-threaded server (MTS) configuration, client user processes connect to a dispatcher. A dispatcher can support multiple client connections concurrently. Each client connection is bound to a virtual circuit. A virtual circuit is a piece of shared memory used by the dispatcher for client database connection requests and replies. The dispatcher places a virtual circuit on a common queue when a request arrives. An idle shared server picks up the virtual circuit from the common queue, services the request, and relinquishes the virtual circuit before attempting to retrieve another virtual circuit from the common queue. This approach enables a small pool of server processes to serve a large number of clients. A significant advantage of the MTS model over the dedicated server model is the reduction of the use of system resources, enabling the support of an increased number of users.

Figure 2-2 shows client connection requests being routed to one dispatcher.

Figure 2-2 MTS Connection Model

When a database has been configured with MTS, incoming network connection requests are always routed to the dispatcher unless either the network session specifically requests a dedicated server or no dispatchers are available. The sequence of events that occurs with the dispatcher is as follows:

1. The listener is started and listens on either a default address or the addresses specified in its configuration file, listener.ora.

2. The database instance is started. Dispatchers start according to the configuration parameters in the initialization parameter file. Each dispatcher then listens on the address assigned to it.

3. Each dispatcher's address is registered with the listener through service registration. It can take up to a minute before the dispatchers are registered with the listener.

   When the listener is not listening on its default address, the listener's network name can be specified in the initialization parameter file. The name can resolve to more than one such address if multiple listeners are used.

   If Step 1 is performed before Step 2, there can be a delay as the server attempts to connect to the listener.

   The listener and the dispatcher are now ready to receive incoming network sessions.

   Note: : You can check which dispatcher addresses have registered with the listener by issuing a SERVICES command from the Listener Control Utility. For more information, see "SERVICES".

4. The client connects to the listener using the listener address in the connect descriptor.

   If connection requests come in a time frame where no dispatchers are registered, these requests can be handled by a dedicated server (configured in the listener.ora file). If you want a client to always a use dispatcher, the client can be configured with (SERVER=SHARED) in the connect data portion of the connect descriptor, as shown in the following example connect descriptor. With this configuration, if no shared servers are available, the client connection request fails.

   sales= 
   (description= 
     (address=(protocol=tcp)(host=sales1-server)(port=1521))
     (connect_data=
       (service_name=sales.us.acme.com)
       (server=shared)))
   

   See Also: "Using MTS on Clients" for information about MTS configuration on clients

5. The listener receives the connect request, and determines if the client's request can be serviced. If not, the listener refuses the network connection request and resumes at Step 8.

6. If the client's request is valid, the listener performs one of the following:
   • The listener hands the connection request directly to a dispatcher.

   • The listener issues a redirect message to the client containing the network address of a dispatcher. The client then dissolves the network session to the listener, and establishes a network session to the dispatcher using the network address provided in the redirect message.

   Direct hand-off to a dispatcher is supported if the dispatcher is local to the listener for the following protocols:

   • IPC protocol

   • TCP/IP protocol

   A redirected connection is used if the dispatcher is remote.

7. The dispatcher updates the listener with significant load information to allow the listener to balance the incoming network connection requests across dispatchers.

8. The listener resumes listening for incoming network sessions.

Figure 2-3 shows the listener handing the connection request directly to the dispatcher.

1. The listener receives a client connection request.

2. The listener hands the connect request directly to the dispatcher.

3. The client connects to the dispatcher.

Figure 2-3 Direct Hand-Off to a Dispatcher

Figure 2-4 shows the role of a dispatcher in a redirected connection.

1. The listener receives a client connection request.

2. The listener provides the location of the dispatcher to the client in a redirect message.

3. The client connects directly to the dispatcher.

Figure 2-4 Redirected Connection to a Dispatcher

Configuration

To enable MTS, the MTS_DISPATCHERS parameter must be set in the initialization parameter file.

See Also: Chapter 9 for information about configuring the MTS_DISPATCHERS parameter

Connection Pooling

Connection pooling is a resource utilization and user scalability feature of MTS that enables you to maximize the number of network sessions over a limited number of connections to a dispatcher. This is achieved by sharing or pooling a set of connections.

Figure 2-5 shows how connection pooling works when the number of connection is set to 255.

Figure 2-5 Connection Pooling

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

See Also: "Enabling Connection Pooling" for configuration information

Dedicated Server Model

Alternatively to MTS, Net8 can direct a client connection request to a dedicated server. In this model, there is one server process for each client. In order for clients to connect to dedicated servers, the listener and the instance must be running on the same machine.

Note: Dedicated server processes require more memory than MTS.

Figure 2-6 shows client requests being routed to dedicated servers.

Figure 2-6 Dedicated Server Model

A client can be configured to override MTS configuration by setting (SERVER=DEDICATED) in the connect data portion of the connect descriptor, as in the following example:

sales= 
(description= 
  (address=(protocol=tcp)(host=sales1-server)(port=1521))
  (connect_data=
    (service_name=sales.us.acme.com)
    (server=dedicated)))

See Also: "Overriding MTS on Clients" for information about overriding MTS configuration on clients

The connection sequence that occurs with a dedicated server is as follows:

1. The listener is started and listens on either a default address or the addresses specified in its configuration file, listener.ora.

2. A database instance is started.

3. The listener is updated with the instance information.

   The listener is now ready to receive incoming network connections.

   Note: : You can check which dedicated server addresses have registered with the listener by issuing a SERVICES command from the Listener Control Utility. For more information, see "SERVICES".

4. The client connects to the listener using the listener protocol address in the connect descriptor.

5. The listener receives the connect request, performs the connection handshake, and determines if the client's request can be serviced. If not, the listener refuses the network connection and resumes at Step 8.

6. The listener spawns a dedicated server, performing one of the following:
   • The listener passes the client connection to the spawned dedicated server.

   • The dedicated server informs the listener of the address that it is listening on. The listener issues a redirect message back to the client and dissolves the connection. The client connects to the dedicated server directly using the address provided in the redirect message.

   The selection of the option is based on the operating system and the protocol being used.

7. The listener resumes listening for incoming network sessions.

Figure 2-7 shows the role of a dedicated server in a redirected connection.

1. The listener receives a client connection request.

2. The listener spawns a dedicated server.

3. The listener provides the location of the dedicated server to the client in a redirect message.

4. The client connects directly to the dedicated server.

Figure 2-7 Redirected Connection to a Dedicated Server Process

Prespawned Dedicated Servers

Net8 provides the option of automatically creating dedicated server processes before a connect request is received. These processes last for the life of the listener, and can be reused by subsequent connection requests.

Note: : Prespawned dedicated servers require SQL*Net version 2.1 or later, and Oracle Server release 7.1 or later.

Figure 2-8 shows client requests being routed to prespawned dedicated servers.

Figure 2-8 Connections To Prespawned Dedicated Servers

The sequence of events that occurs when using prespawned dedicated server processes to service client connection requests is as follows:

1. The listener is started and listens on an address specified in its configuration file, listener.ora.

2. The listener spawns a series of dedicated servers until it reaches the specified pool size defined in its configuration file.

3. Each spawned server performs a partial address listen and provides the listener with the address that it is listening on. In a partial address listen, the server process listens, but informs the underlying protocol stack that it has no preference as to the specific address it listens on. As a result, many protocol stacks choose a free listening address and automatically assign this to the requesting server process. The listener initially marks all prespawned servers as idle.

4. The client sends a connect request to the listener.

5. The listener receives the network connection request, and determines if the client's request can be serviced. If not, the listener refuses the network connection and resumes at Step 9.

6. The listener issues a redirect message to the client containing the full network address of one of the prespawned dedicated servers. The listener logs that server process as active.

7. The client dissolves the network connection to the listener and establishes a network connection to the prespawned dedicated server using the address provided in the redirect message.

8. The listener spawns another server process to replace the active prespawned dedicated server, provided a value called PRESPAWN_MAX in the listener.ora file is greater than the total number of existing prespawned dedicated server processes (active or idle) and that the POOL_SIZE (number of idle prespawn processes) has not been reached.

9. The listener continues listening for incoming network sessions.

The above sequence of events continues until the maximum prespawn limit is reached. At this point the listener stops prespawning new dedicated server processes.

When client disconnects, the prespawned dedicated server process associated with the client returns to the idle pool and waits a specified length of time to be assigned to another client. If no client is handed to the prespawned server before the timeout expires, the prespawned server shuts down.

Figure 2-9 shows a listener spawning a prespawned dedicated server before the connection request and redirecting the connection back to the client.

1. The listener spawns a prespawned dedicated server.

2. The listener receives a client connection request.

3. The listener provides the location of the prespawned dedicated server to the client in a redirect message.

4. The client connects directly to the prespawned dedicated server.

5. The listener spawns another prespawned dedicated server.

Figure 2-9 Redirected Connection to a Prespawned Dedicated Server Process

Configuration

The use of prespawned dedicated servers requires specification of parameters in the listener configuration file.

See Also: "Configuring Prespawned Dedicated Servers" for configuration information

Bequeathed Network Sessions Directly to Dedicated Servers

If the client and server exist on the same machine, a client connection can be bequeathed (passed) directly to a dedicated server process without going through the listener. The application initiating the session spawns a dedicated server process for the connection request using the Bequeath protocol.

This happens automatically if an application is used to start the database on the same machine as the database, as in the following:

SQLPLUS

SQL> connect internal/password 

Client Connection Options

Client connections can be customized with the options described in the following sections:

• Client Load Balancing for Multiple Listeners

• Connect-Time Failover for Multiple Listeners

• Transparent Application Failover for High Availability

Client Load Balancing for Multiple Listeners

When more than one listener supports a service, a client can randomize requests to the various listeners. This feature, called client load balancing, distributes the load so as not to overburden a single listener.

Configuration

To enable your clients to choose from listeners at random, configure a connect descriptor with multiple listening addresses, and set the LOAD_BALANCE parameter to on, as in the following:

sales= 
 (description= 
  (load_balance=on)
  (address=(protocol=tcp)(host=sales1-server)(port=1521))
  (address=(protocol=tcp)(host=sales2-server)(port=1521))
  (connect_data=
   (service_name=sales.acme.com)))

Client load balancing can be used in conjunction with connect-time failover.

See Also: "Configuring Address List Parameters" for configuration information

Connect-Time Failover for Multiple Listeners

When more than one listener supports a service, a client can be configured to failover the client request to a different listener if the first listener fails. Reconnection attempts continue until the client successfully connects to a listener.

Configuration

To control how the client executes these connection attempts, configure a connect descriptor with multiple listening addresses and set the FAILOVER parameter to on, as in the following:

sales= 
 (description= 
  (failover=on)
  (address=(protocol=tcp)(host=sales1-server)(port=1521))
  (address=(protocol=tcp)(host=sales2-server)(port=1521))
  (connect_data=
   (service_name=sales.acme.com)))

Connect-time failover can be used in conjunction with client load balancing.

See Also: See "Configuring Address List Parameters" for configuration details

Transparent Application Failover for High Availability

Transparent Application Failover (TAF) is a runtime failover for high-availability environments, such as Oracle Parallel Server and Oracle Fail Safe, that refers to the failover and re-establishment of application-to-service connections. It enables client applications to automatically reconnect to the database if the connection fails, and optionally resume a SELECT statement that was in progress. This reconnect happens automatically from within the Oracle Call Interface (OCI) library.

See Also: Oracle8i Concepts

Configuration

To enable TAF, configure a connect descriptor with the FAILOVER_MODE parameter in the connect data portion of the connect descriptor.

See Also: "Configuring Transparent Application Failover" for configuration details

Service Registration to the Listener

The PMON process--an instance background process--registers instance information with a listener, as well as the current state and load of the instance and MTS dispatchers. This registration process is called service registration. The registered information enables the listener to forward client connection requests to the appropriate service handler.

Figure 2-10 shows instances registering information with listeners.

Figure 2-10 Service Registration

Service registration provides the listener with information about:

• Service names for each running instance of the database

• Instance names of the database

• Service handlers (dispatchers and dedicated servers) available for each instance

  This enables the listener to direct a client's request appropriately.

• Dispatcher, instance, and node load information

  This load information enables the listener to determine which dispatcher can best handle a client connection's request. If all dispatchers are blocked, the listener can spawn a dedicated server for the connection.

When an instance is started, initialization parameters are read from the initialization parameter file. By default, PMON registers information with a listener on the local machine at a well-known address.

If the listener is not up when an instance starts, PMON is not able to register information. However, it attempts to connect to the listener periodically. If a listener receives an incoming request before the respective instance has been registered, the listener rejects the request.

Benefits

Service registration offers the following benefits:

Benefit	Description
Configuration	Reduces the need for the listener.ora file. Note: The SID_LIST_listener_name parameter that specifies information about the databases served by the listener is still required if you are using Oracle Enterprise Manager to manage the database.
Connect-Time Failover for MTS	Because service registration enables the listener to always know if an instance is up, this facilitates automatic failover of the client connect request to a different instance if one instance is down. In a static configuration model, a listener would start a dedicated server on receiving a client request. The server would later find out that the instance is not up yet, causing an "Oracle not available" error message. See Also: "Connect-Time Failover for Multiple Listeners"
Connection Load Balancing	Service registration enables the listener to forward client connect requests to the least loaded dispatcher. This enables the listener to balance the load across the service handlers and nodes. In an Oracle Parallel Server environment, service registration is also able to detect the least loaded instance. See Also: "Connection Load Balancing"

Registration with the Default Local Listener

By default, PMON registers with the local listener on server at the default local address of TCP/IP, port 1521.

Registration with a Non-Default Listener

If you want PMON to register with a local listener on the server that does not use TCP/IP, port 1521, configure the LOCAL_LISTENER parameter in the initialization parameter file to locate the local listener. The LOCAL_LISTENER parameter should be configured as follows:

local_listener=listener_alias

listener_alias is then resolved through a naming method, such as the tnsnames.ora file on the server.

For example, the LOCAL_LISTENER parameter can be set as follows:

local_listener=listener1

listener1 can be resolved through a local tnsnames.ora file as follows:

listener1= 
(description= 
  (address=(protocol=tcp)(host=sales-server)(port= 1421)))

See Also: "Configuring the LOCAL_LISTENER Parameter" for information about setting LOCAL_LISTENER

Registration with Remote Listeners

Registration to remote listeners, such as in the case of Oracle Parallel Server, can be configured for MTS environments by using the LISTENER attribute of the MTS_DISPATCHERS parameter. The LISTENER attribute should be set as follows:

mts_dispatchers="(protocol=tcp)(listener=listener_alias)"

listener_alias is resolved through a naming method, such as tnsnames.ora file.

For example, the MTS_DISPATCHERS parameter can be set as follows in the initialization parameter file:

mts_dispatchers="(protocol=tcp)(listener=listeners_sales)"

listeners_sales can be then resolved through a local tnsnames.ora file as follows:

listeners_sales= 
 (description= 
  (address_list=
   (address=(protocol=tcp)(host=sales1-server)(port= 1521))
   (address=(protocol= tcp)(host=sales2-server)(port=1521))))

Configuration

To enable service registration, the initialization parameter file must contain the following parameters:

• SERVICE_NAMES for the database service name

• INSTANCE_NAME for the instance name

For example:

service_names=sales.us.acme.com
instance_name=sales

See Also: Oracle8i Reference for further information about the SERVICE_NAMES and INSTANCE_NAME parameters "Configuring a Listener that Uses a Non-Default Address" for further information about the LOCAL_LISTENER parameter

Connection Load Balancing

Connection load balancing improves connection performance by balancing the number of active connections among multiple dispatchers. In an Oracle Parallel Server environment, connection load balancing also has the capability to balance the number of active connections among multiple instances.

Because PMON can register with remote listeners, a listener can always be aware of all instances and dispatchers regardless of their location. Depending on the load information, a listener decides which instance and which dispatcher to send the incoming client request to. Thus, when a listener gets an incoming request, it selects the dispatcher in the following order: a) least loaded node, b) least loaded instance, and c) least loaded dispatcher for that instance.

If a database service has multiple instances on multiple nodes, the listener chooses the least loaded instance on the least loaded node. Based on the selected instance, the least loaded dispatcher is then chosen.

Configuration

To enable connection load balancing, the initialization parameter file must contain the following parameters:

• SERVICE_NAMES for the database service name

• INSTANCE_NAME for instance name

• MTS_DISPATCHERS to enable MTS and specify the dispatchers used by the instance

For example:

service_names=sales.us.acme.com
instance_name=sales
mts_dispatchers="(protocol=tcp)(dispatchers=2)(listener=listeners_sales)"

An Oracle Parallel Server environment requires that the dispatchers on each instance be cross registered with the other listeners on the other nodes. This is achieved by the use of the LISTENER attribute of the MTS_DISPATCHERS parameter.

See Also: "Registration with Remote Listeners" for complete information about cross registration Oracle8i Reference for complete information about the SERVICE_NAMES and INSTANCE_NAME parameters Chapter 9 for complete information about the LISTENER attribute

Note: For optimum connection load balancing results, the instances that belong to the same database service should be on equivalent hardware and software configurations.

Example

Figure 2-11 shows an Oracle Parallel Server database with two instances, sales1 and sales2, of the same service, sales.us.acme.com. The instances sales1 and sales2 reside on machines sales1-server and sales2-server, respectively. sales1 has one dispatcher and sales2 has two dispatchers. Listeners named LISTENER run on nodes 1 and 2, respectively. The LISTENER attribute in the MTS_DISPATCHER parameter has been configured to allow for service registration of information to both listeners.

Figure 2-11 Load Balancing Environment

The listeners_sales value in (listener=listeners_sales) can be then resolved through a local tnsnames.ora file on the both servers as follows:

listeners_sales= 
 (description= 
  (address_list=
   (address=(protocol=tcp)(host=sales1-server)(port= 1521))
   (address=(protocol= tcp)(host=sales2-server)(port=1521))))

Based on the environment, the following actions occur. The numbered actions correspond to the arrows shown in Figure 2-12:

1. PMON processes for instances sales1 and sales2 register with both listeners. The listeners are updated on the load of the instances and dispatchers dynamically, and the following load information is registered:

   	dispatcher1	dispatcher2	dispatcher 3
   Number of Connections	200	100	200

   	sales1	sales2
   Number of Connections	200	300

   	sales1-server	sales2-server
   1 Minute Load Average	600	400

   The number of connections for sales1 (200) is the same as that of its only dispatcher, dispatcher1. However, the number of connections on sales2 (300) is the sum of the connections on its two dispatchers, dispatcher2 (100) and dispatcher 3 (200). Therefore, sales2 has more connections than sales1. However, the load average on sales2-server (400) is less than the load average on sales1-server (600). This can happen if more processing is required on sales1-server.

2. The client sends a connect request.

   A connect descriptor is configured to try each listener address randomly until one succeeds:

   sales.us.acme.com= 
    (description= 
     (load_balance=on)
     (failover=on)
     (address=(protocol=tcp)(host=sales1-server)(port=1521))
     (address=(protocol=tcp)(host=sales2-server)(port=1521))
     (connect_data=(service_name=sales.acme.com)))
   
   

   The listener on sales1-server was randomly chosen to receive the client connect request.

   The listener on sales1-server compares the load of the instances sales1 and sales2. The comparison takes into account the load on nodes sales1-server and sales2-server, respectively. Since sales2-server is less loaded than sales1-server, the listener chooses sales2-server over sales1-server.

3. The listener compares the load on dispatchers dispatcher2 and dispatcher3. Since dispatcher2 is less loaded than dispatcher3, the listener redirects the client connect request to dispatcher2.

4. The client connects directly to dispatcher2.

Figure 2-12 Load Balancing Example

Database Identification by Service Name Rather than SID

An Oracle database can span multiple instances over multiple computers, making the database service a distributed service.

Prior to Oracle8i, an Oracle database service was identified by an Oracle System Identifier (SID), a name that identifies a specific instance of a database. Clients connected to a database instance by specifying the SID in the connect descriptor. This naming scheme did not distinguish services from instances.

In Oracle8i, a new naming scheme has been implemented. Because an Oracle database can span multiple computers, both the service as a whole and each of its instances are specified.

A database service is now identified by its service name with the SERVICE_NAMES parameter in the initialization parameter file. SERVICE_NAMES specifies the name of the highest-level view of Oracle database service, which can span instances and nodes. SERVICE_NAMES is defaulted to the global database name, a name comprised of the database name (DB_NAME) and domain name (DB_DOMAIN).

Database instances are identified by an instance name with the INSTANCE_NAME parameter in the initialization parameter file. INSTANCE_NAME corresponds to the SID of the instance.

This section includes the following topics:

• Connect Descriptors Using SERVICE_NAME and INSTANCE_NAME

• Multiple Instances Belonging to the Same Service

• Single Instance Belonging to Multiple Services

Connect Descriptors Using SERVICE_NAME and INSTANCE_NAME

Connect descriptors used by clients should be configured with the SERVICE_NAME (without an S) parameter to connect to an Oracle8i database. For example, the following connect descriptor contains the address of a listener located on sales1-server listening for connection requests for a database service called sales.us.acme.com:

sales= 
 (description= 
  (address=(protocol=tcp)(host=sales1-server)(port=1521))      
  (connect_data=
   (service_name=sales.us.acme.com)))

Optionally, the connect descriptor can be configured with the INSTANCE_NAME parameter (in addition to the SERVICE_NAME parameter) to connect to a particular instance of the database. This can be useful if you have an Oracle Parallel Server with multiple instances.

For example, the following connect descriptor contains the address of a listener located on sales1-server listening for connection requests for an instance called sales1 associated with the sales.us.acme.com database:

sales= 
 (description= 
  (address=(protocol=tcp)(host=sales1-server)(port=1521))      
  (connect_data=
   (instance_name=sales1)
   (service_name=sales.us.acme.com)))

Multiple Instances Belonging to the Same Service

Multiple database instances can run on different machines, as is the case for Oracle Parallel Server environments, and can access the same data, but they belong to the same service.

In the case of multiple instances, the listener performs connection load balancing to find the least loaded instance and least loaded dispatcher. Clients that specify the SERVICE_NAME parameter in the connect descriptor are directed to the instance and dispatcher with the least load.

If using a specific instance is required, clients can also specify the INSTANCE_NAME of a particular instance in the connect descriptor. This way, clients are connected to the instance as long as the instance belongs to the specified service.

Single Instance Belonging to Multiple Services

A database service can be represented by multiple service entries of the SERVICE_NAMES parameter in the initialization parameter file. This feature enables the following:

• A single instance to be identified in a number of different ways by different clients

• A database administrator to limit resources allocated or reserved for servicing clients requesting one of these services

For example, the initialization parameter file can be configured with:

service_names=sales1.us.acme.com, sales2.us.acme.com

With this configuration, a pool of MTS dispatchers can be allocated exclusively for clients requesting sales1.us.acme.com. Other clients, requesting sales2.us.acme.com, can be forced to use another dispatcher to handle their requests. This way, mission critical requests can be provided with more resources and a higher priority.

See Also: "Allocating Resources" for an example of resource allocation

Migration

The migration from the old naming scheme to the new one should be done as soon as possible to take full advantage of current functionality. New features in the future will not permit the use of SID in the client connect descriptor.

See Also: see Oracle8i Migration

Service Resolution through Naming Methods

Connect descriptors are resolved through one or more naming methods. A naming method refers to the resolution method used by Net8 to resolve a name to a network description. Net8 provides the following naming methods:

• Local Naming

• Directory Naming

• Oracle Names

• Host Naming

• External Naming

Local Naming

Local naming resolves a net service name to a network address by using information configured in a local naming configuration file called tnsnames.ora.

See Also: "Configuring the Local Naming Method" for configuration details

Establishing a Connection Using Local Naming

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

1. The client initiates a connect request providing a net service name.

2. The net service name is resolved to a connect descriptor configured in a tnsnames.ora file

3. The client makes the connect request to the address provided in the connect descriptor.

4. A listener receives the request and directs it to the appropriate server.

5. The connection is accepted by the server.

Directory Naming

With directory naming, clients can use network information stored in a centralized LDAP-compliant directory server to access a database service.

See Also: "Net8 and an LDAP-Compliant Directory Server" for conceptual information "Configuring the Directory Naming Method" for configuration information

Establishing a Connection Using Directory Naming

The process for establishing a client session using directory naming is as follows:

1. The client initiates a connect request providing a connect identifier.

2. The connect identifier is resolved to a connect descriptor by a directory server. This information is returned to the client.

3. The client makes the connect request to the address provided in the connect descriptor.

4. A listener receives the request and directs it to the appropriate server.

5. The connection is accepted by the server.

Oracle Names

Oracle Names uses Oracle proprietary software 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 an Oracle Names server. Oracle Names servers resolve the name to a network address and return that information to the client.

See Also: "Oracle Names" for product information "Configuring the Oracle Names Method" for configuration details

Establishing a Connection Using Oracle Names

The process for establishing a client session using the Oracle Names option is as follows:

1. The client initiates a connect request providing a connect identifier.

2. The connect identifier is resolved to a connect descriptor by an Oracle Names server. This information is returned to the client.

3. The client makes the connect request to the address provided in the connect descriptor.

4. A listener receives the request and directs it to the appropriate server.

5. The connection is accepted by the server.

Host Naming

Host naming enables users to connect to an Oracle server by using a host name alias. Host names are mapped to the server's global database name in an existing names resolution service, such as Domain Name System (DNS), Network Information Service (NIS), or a centrally-maintained set of /etc/hosts files.

The connection is established by using the default TCP/IP port for the listener, 1521. Multiple databases per node and database location transparency are supported through matching global database names with host name aliases.

Host naming eliminates the need for a tnsnames.ora file in environments where simple database connectivity is desired. It is not appropriate for environments that use Oracle Connection Manager, are not using TCP/IP, or require Transparent Application Failover.

See Also: "Configuring the Host Naming Method" for configuration details

Establishing a Connection Using Host Naming

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

1. The client initiates a connect request providing a TCP/IP host name alias.

2. Host naming resolves the host name or alias by generating a network address using the net service name as both the TCP/IP host name and the service name. The TCP/IP port defaults to 1521.

3. Net8 sends the connect request to the address created.

4. A listener, listening at registered TCP/IP port 1521, receives the request and establishes a connection to the appropriate server.

5. The connection is accepted by the appropriate server.

External Naming

External naming refers to the method of resolving a net service name to a network address by using a supported non-Oracle naming service. External naming resolves net service names stored in customers' external non-Oracle naming services. They include the following:

• Network Information Service (NIS) External Naming

• Novell Directory Services (NDS) External Naming

• Distributed Computing Environment (DCE) Cell Directory Service (CDS)

  See Also: "Configuring External Naming Methods" for configuration details

Establishing a Connection Using External Naming

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

1. The client initiates a connect request providing a net service name.

2. An external naming method forwards the request to an external naming system that resolves the net service name to a network address. The address is returned to the client.

3. Net8 sends the connect request to the address provided.

4. A listener receives the request and directs it to the appropriate database.

5. The connection is accepted by the server.

Net8 and an LDAP-Compliant Directory Server

This section contains the following topics:

• Overview

• Directory Naming Overview

• Directory Entries

• Adding or Modifying Entries in the Directory

• Client Connections Using Directory Naming

• Specifying Absolute Names

• Net8 Naming and Directory Design

Overview

Today, network information is stored in multiple systems and in multiple directory formats. With new requirements for Internet computing and new e-business technologies, there is a growing need for a common repository infrastructure to serve as a foundation for management and configuration of all data and resources. Such a common infrastructure reduces the cost of managing and configuring resources in heterogeneous networks.

Support of LDAP-compliant directory servers provides a centralized vehicle for managing and configuring a distributed Oracle network. The directory can act as a central repository for all data on database network components, user and corporate policies, and user authentication and security, thus replacing client-side and server-side localized tnsnames.ora files.

Net8 uses a centralized directory server as one of the primary methods for storage of connect identifiers. Clients, configured to access the directory, use the connect identifiers in their connect string. The directory resolves the connect identifier to a connect descriptor that is passed back to the client.

Figure 2-13 shows a client resolving a connect identifier through a directory.

1. The client contacts the directory to resolve a connect identifier to a connect descriptor.

2. The directory resolves the connect identifier and retrieves the connect descriptor to the client.

3. The client sends the connection request using the connect descriptor.

Figure 2-13 Client Using a Directory to Resolve a Connect Identifier

Net8 supports the following directories:

• Oracle Internet Directory

• Microsoft's Active Directory

• Novell Directory Services

Directory Naming Overview

To understand how Net8 uses a directory, consider Figure 2-14.

Figure 2-14 Database Service in a Directory

Each node in the tree is an entry. The branch on the right represents the entry for a database service called sales, which resides under a hierarchical domain structure of dc=uk,dc=acme,dc=com.

This hierarchy of entries is called the Directory Information Tree (DIT). Each entry is uniquely identified by a Distinguished Name (DN). The DN tells you exactly where the entry resides in the directory's hierarchy. The DN for sales is (dn:cn=sales,cn=OracleContext,dc=uk,dc=acme,dc=com). Note that the format of a DN places the lowest component of the DIT to the left, then moves progressively up the DIT. Each DN is made up of a sequence of Relative Distinguished Names (RDNs), much the way a directory path contains a sequence of directories. In the entry for sales, the RDN is cn=sales. A RDN is made up of a set of attributes. For example, in cn=sales, cn is one of the entry's attributes. The attribute, along with its value, uniquely identifies the entry.

Common attributes referred to in this chapter include:

Attribute	Description
commonName, cn	Common name of an entry
country, c	Name of country
domain component, dc	Domain component
organization, o	Name of organization
organizationalUnitName, ou	Name of a unit within an organization

Notice that sales resides under cn=OracleContext. cn=OracleContext is a special entry in the directory called an Oracle Context that contains various Oracle entries to support directory naming and enterprise user security.

See Also: Oracle Advanced Security Administrator's Guide for further information about enterprise user security

In this example, the Oracle Context contains an entry for the sales database service.

During directory access configuration, completed with Net8 Configuration Assistant during or after installation, an administrative context is selected. The administrative context is a directory entry that contains an Oracle Context (cn=OracleContext). The client uses this administrative context as the default place to locate connect identifiers in the directory.

The administrative context affects the connect string. For example, if a client needs to access the sales entry frequently, a reasonable administrative context would be dc=uk,dc=acme,dc=com. Note that cn=OracleContext is not needed. This enables the client to use the following connect string:

CONNECT scott/tiger@sales

sales is relative to the Oracle Context.

In the case where a client's administrative context does not match the administrative context where the service is located, the connect string must specify an entry's absolute name, as described in "Client Connections Using Directory Naming".

Directory Entries

DITs can be structured in many ways, using:

• Existing Domain Name Space (DNS)

• Internet naming scheme

• Geographical and organization lines

Figure 2-15 shows a DIT structured according to DNS domain components.

Figure 2-15 Domain Component DIT

Figure 2-16 shows a DIT structured according to country, organization, and organizational units. This structure is commonly referred to as an X.500 DIT.

Figure 2-16 X.500 Style DIT

Adding or Modifying Entries in the Directory

A database service entry is created with Oracle Database Configuration Assistant during installation; net service name entries can be created with Net8 Assistant. Net8 Assistant can also be used to modify the Net8 attributes of the database service entry and the net service name entries. Figure 2-17 shows how Oracle Database Configuration Assistant and Net8 Assistant interface with the directory.

Figure 2-17 Creating Entries in the Directory with Applications

Clients configured for directory access, as described in "Client Connections Using Directory Naming", can use entries created by these applications to connect to a database.

In order to add entries with these application, an Oracle Context (cn=OracleContext) must be created. The Oracle Context is created during directory access configuration on the server with Net8 Configuration Assistant.

The administrator using Oracle Database Configuration Assistant must be a member of the OracleDBCreators group (cn=OracleDBCreators,cn=Oraclecontext) to create a database service entry. Likewise, the administrator using Net8 Assistant to add net service names or Net8 attributes for database service or net service names entries must be a member of the OracleNetAdmins group (cn=OracleNetAdmins,cn=OracleContext). The directory user that created the Oracle Context is automatically added to both these groups, making this user the Oracle Context administrator. Other users can be added to this group by the directory administrator.

Client Connections Using Directory Naming

Most clients only need to perform name lookups in the directory. To perform a lookup, the following minimum requirements must be met:

• The client has anonymous authentication with the directory.

• The client has read access to Net8 entries located in the Oracle Context

• The client is configured for directory service access.

The Net8 Configuration Assistant typically performs the necessary directory access configuration during client installation and stores the following information in a read-only ldap.ora file:

• Type of directory

• Location of the directory

• Administrative context from which to look up, create, and modify connect identifiers

The client reads this file to locate the directory and Net8 entries to access.

See Also: "Task 1: Configure Directory Access on Server and Clients" for information about configuring directory access

In the same way they might use other naming methods, clients can make connections to a database using one of the two types of connect identifiers that can stored in the directory. Database service and net service entries can be referred to by their common names, or they can require additional directory location information in the connect string. How the connect identifier is specified in a connect string depends on how the client's administrative context is configured.

With directory naming, there are two ways in which to identify an entry:

• Using the Entry's Relative Name

• Using the Entry's Absolute Name

Using the Entry's Relative Name

The following example demonstrates using an entry's relative name, whereby the service can be referred to by its common name. A relative name can be used if the client is configured with an administrative context that matches the administrative context for the entry in the directory.

Consider a directory that contains an entry for a database called sales with a DN of (dn:cn=sales,cn=OracleContext,o=acme,c=us), as shown in Figure 2-18. If the client is configured with an administrative context of o=acme,c=us, a connect string that uses sales can be used.

Figure 2-18 Relative Naming

Using the Entry's Absolute Name

Consider the same directory structure as Figure 2-18, but with a client configured with an administrative context of dc=uk,dc=acme,dc=com.

Because the client is configured with an administrative context that does not match the location of sales in the directory, a connect string that uses sales does not work. Instead, the client must specifically identify the location of sales. sales which can be identified in two ways:

• The entry's complete DN can be used in the connect string, for example:

  CONNECT scott/tiger@cn=sales,cn=OracleContext,o=acme,c=us
  
  

• The entry can be referred to by its absolute name, a name that includes the name of the object and its location in the directory, much the way an absolute path is specified, for example:

  CONNECT scott/tiger@sales.acme.us
  
  

Oracle Corporation recommends using an entry's absolute name rather than the entry's DN.

See Also: "Specifying Absolute Names" for further information about absolute names

Specifying Absolute Names

This section describes how to configure absolute names for the following namespaces:

• Absolute Names for X.500 Namespaces

• Absolute Names for Domain Component Namespaces

Absolute Names for X.500 Namespaces

For X.500 namespaces, the administrative context must be in one of the following formats:

[ou],o

[ou],o,c

where [ou] represents an optional organizationalUnitName.

The absolute name the client uses as the connect identifier must be in one of the following formats:

cn[.ou].o

cn[.ou].o.c

where [cn] represents the Net8 entry.

For example, consider a client that has been configured with an administrative context of ou=acctg,o=acme,c=us.

The directory contains an entry for a database called sales with a DN of (dn:cn=sales,cn=OracleContext,ou=mktg,o=acme,c=uk). In this scenario, the client requires a connect identifier of sales.mktg.acme.uk (cn.ou.o.c). Figure 2-19 depicts this example.

Figure 2-19 Absolute Name for X.500 Namespaces

Absolute Names for Domain Component Namespaces

For domain component namespaces, the administrative context defined for the client must be in one of the following formats:

dc[,dc]*

ou,dc[,dc]*

where [dc] represents an optional domain component and * represents additional domain component entries.

The absolute name the client must use in the connect identifier must be in one of the following formats:

cn.dc[.dc]*

cn[.ou]@dc[.dc]*

where [cn] represents the Net8 entry.

Example 1

Consider a client that has been configured with an administrative context of dc=us,dc=acme,dc=com.

The directory contains an entry for a database called sales with a DN of (dn:cn=sales,cn=OracleContext,dc=uk,dc=acme,dc=com). In this scenario, the client requires a connect identifier of sales.uk.acme.com (cn.dc.dc.dc). Figure 2-20 depicts this example.

Example 2

Consider the same administrative context as Example 1. The directory contains an entry for a database called sales with a DN of (dn:cn=sales,cn=OracleContext,ou=mktg,dc=uk,dc=acme,dc=com). Notice ou=mktg. Because domain components must be separated from organization units, the client requires a connect identifier of sales.mktg@uk.acme.com (cn.ou@dc.dc.dc). Figure 2-20 depicts this example.

Figure 2-20 Absolute Name for Domain Component Namespaces

Net8 Naming and Directory Design

If you are responsible for designing directories with Net8 usage, consider the following issues:

• Performance

• Security

• Schema

Performance

Connect identifiers are stored in a directory for all clients to access. Net8 uses a directory lookup for the requested name, resulting in heavy use of the directory.

During a lookup, a name is searched under a specific Oracle Context. Because of the scope of the lookup, you probably want users to experience relatively quick performance. Otherwise, the database connect time is affected. Users can begin to notice slow connect time if the lookup takes more than one second.

Performance problems can be resolved by the following:

• Topology changes

• Replication

  See Also: Directory documentation for details on resolving performance issues

Security

Because administrative clients can create and modify entries in the directory, security is essential. The covers the following security-related topics in the following sections:

• Authentication Methods

• Access Control Lists

Authentication Methods

Clients that perform typical lookups for information in the directory typically use anonymous authentication.

Clients that add or modify entries in a directory, with Oracle Database Configuration Assistant or Net8 Assistant, must authenticate with the directory. Only authenticated users with proper privileges can modify entries. One of the following authentication methods can be used:

Authentication Method	Description
Native Authentication	The directory uses operating system user credentials.
Simple Authentication	The client identifies itself to the directory server by means of a DN and a password, which are sent in the clear over the network. The server verifies that the DN and password sent by the client match the DN and password stored in the directory.
Strong Authentication	Directories provide strong authentication by using public-key encryption available with Secure Sockets Layer (SSL). In public-key encryption, the sender of a message encrypts the message with the public key of the recipient. Upon delivery, the recipient decrypts the message using the recipient's private key.

Access Control Lists

Authentication is used in with Access Control Lists (ACLs) to make decisions about whether clients can modify or add information in the directory. ACLs are created with the Oracle Context with Net8 Configuration Assistant during directory access configuration on the server.

ACLs specify the following:

• The entries the user can access

• The authentication method to access the entry

• The access rights, or what the user can do with the object (read/write)

ACLs are established for a group of users. During Oracle Context creation, the following groups are created:

• OracleDBCreators

• OracleNetAdmins

• OracleSecurityAdmins

These groups are created directly under the Oracle Context, as shown in Figure 2-21.

Figure 2-21 Directory User Groups

The user who creates the Oracle Context with Net8 Assistant Configuration Assistant is automatically added as the first member of these groups.

The following table describes ACL requirements for these groups and anonymous users as they relate to Net8 entries in the directory:

Group	ACL Requirements
OracleNetAdmins group users	Members of OracleNetAdmins (cn=OracleOracleNetAdmins,cn=OracleContext) have create, modify, and read access to Net8 objects and attributes. Net8 Assistant Configuration Assistant establishes these access rights for this group during Oracle Context creation. In addition to the Oracle Context creator, other users can be added to this group by the directory administrator. See Also: "Adding Users to and Removing Users from the OracleNetAdmins Group" to add users to the OracleNetAdmins group
Anonymous users	All Net8 attributes and objects in the directory have read access for the anonymous user. Read access of these object for anonymous is also be applied to the Oracle Context. This enables anonymous users to browse entries contained with the cn=OracleContext RDN. This does not include objects used for enterprise user security. Net8 Assistant Configuration Assistant sets up this access right during client installation.
OracleDBCreators group users	Members of OracleDBCreators (cn=OracleDBCreators,cn=OracleContext) have create and read access to database service objects and attributes.Net8 Assistant Configuration Assistant establishes these access rights for this group during Oracle Context creation. In addition to the Oracle Context creator, other users can be added to this group by the directory administrator with Oracle Enterprise Security Manager. See Also: Oracle Advanced Security Administrator's Guide for further information about the OracleDBCreators group
OracleSecurityAdmins group users	Members of OracleSecurityAdmins (cn=OracleOracleSecurityAdmins,cn=OracleContext) have create, modify, and read access for enterprise user security. Net8 Assistant Configuration Assistant sets up these access rights during Oracle Context creation. In addition to the Oracle Context creator, other users can be added to this group by the directory administrator with Oracle Enterprise Security Manager. See Also: Oracle Advanced Security Administrator's Guide for further information about the OracleSecurityAdmins group

Schema

Directories must be populated with the correct version of the Oracle schema for Net8 clients to look up network information for a service. The Oracle schema defines the type of objects, called object classes, that can be stored in the directory and their attributes. The Oracle schema supports the following object classes for Net8 lookups.

Object Class	Description
orclDbServer	Defines the attributes for database service entries
orclNetService	Defines the attributes for net service name entries

orclDbServer and orclNetService use the following object classes:

Object Class	Description
orclNetAddress	Defines a listener protocol address
orclNetAddressList	Defines a list of addresses
orclNetDescription	Specifies a connect descriptor, containing the listener address for the database and the connect information to the service.
orclNetDescriptionList	Defines a list of connect descriptors