Skip Headers

Oracle9i Net Services Administrator's Guide
Release 2 (9.2)

Part Number A96580-02
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Master Index
Master Index
Go to Feedback page

Go to previous page Go to next page
View PDF

Configuring Shared Server

The shared server architecture enables a database server to allow many user processes to share very few server processes, so the number of users that can be supported is increased. With shared server, many user processes connect to a dispatcher. The dispatcher directs multiple incoming network session requests to a common queue. An idle shared server process from a shared pool of server processes picks up a request from the queue. This means a small pool of server processes can serve a large number of clients.

This chapter describes how to configure shared server. It contains these topics:

Configuring Shared Server with the DISPATCHERS Parameter

To enable a shared server configuration, set the DISPATCHERS parameter in the database initialization parameter file.


Database Configuration Assistant enables you to configure this parameter.

After setting this parameter, restart the instance to enable shared server configuration. Set DISPATCHERS as follows:


One of the following attributes is required to enable shared server:

The following attributes are optional:

Setting the Initial Number of Dispatchers

The number of dispatchers started at instance startup is controlled by the DISPATCHERS attribute.


Unlike the number of shared server processes, the number of dispatchers does not change automatically. The number of dispatchers can be explicitly changed with the SQL statement ALTER SYSTEM. You can change the number of dispatchers in this manner up to a maximum limit specified by the MAX_DISPATCHERS parameter. See the Oracle9i SQL Reference for further information about the ALTER SYSTEM statement and the Oracle9i Database Performance Tuning Guide and Reference for further information about the DISPATCHERS parameter.

The appropriate number of dispatchers for each instance depends upon the performance you want from your database, the host operating system limit on the number of connections for each process, which is operating system dependent, and the number of connections required for each network protocol.

Calculating the Initial Number of Dispatchers

Once you know the number of possible connections for each process for the operating system, calculate the initial number of dispatchers to create during instance startup, for each network protocol, using the following formula.

number                 maximum number of concurrent sessions
of           = CEIL   (--------------------------------------------------------------------------)
dispatchers                connections for each dispatcher

CEIL represents the number roundest to the next highest whole integer.

Example: Initial Number of Dispatchers

Assume a system that has:

In this case, the DISPATCHERS attribute for TCP/IP should be set to a minimum of four dispatchers and TCP/IP with SSL should be set to a minimum of three dispatchers:


Depending on performance, you may need to adjust the number of dispatchers.

Example: Dispatcher Address with IP Address

To force the IP address used for the dispatchers, set the following:


This starts two dispatchers that listen on host Note that Oracle Net dynamically selects the TCP/IP port for the dispatcher.

Example: Dispatcher Address with PORT

To force the exact location of the dispatchers, add the PORT as follows:



You can specify multiple DISPATCHERS in the initialization file, but they must be adjacent to each other.

Enabling Connection Pooling

Connection pooling is a resource utilization feature that enables you to reduce the number of physical network connections to a dispatcher. This is achieved by sharing or pooling a set of connections among the client processes.

To configure connection pooling, set the DISPATCHERS parameter in the initialization parameter file with the POOL attribute and the following optional attributes:

Refer to the example in "Example: Initial Number of Dispatchers". Connection pooling can allow each dispatcher 1,000 connections and 4,000 sessions for TCP/IP and 2,500 sessions for TCP/IP with SSL. This reduces the configuration to one dispatcher for each protocol, as shown in the following:



See Also:

"Connection Pooling"

Allocating Resources

An Oracle database can be represented by multiple service names. Because of this, a pool of dispatchers can be allocated exclusively for clients requesting a particular service. This way, the mission critical requests may be given more resources and, thus, in effect increase their priority.

For example, the following initialization parameter file sample shows two dispatchers. The first dispatcher services requests for clients requesting The other dispatcher services requests only for clients requesting

Using Shared Server on Clients

If shared server is configured and a client connection request arrives when no dispatchers are registered, the requests can be handled by a dedicated server process (configured in the listener.ora file). If you want a particular client always to use a dispatcher, configure (server=shared) in the connect data portion of the connect descriptor. For example:


If a dispatcher is not available, the client connection request is rejected.

See Also:

"Configuring Advanced Connect Data Parameters" to set the SERVER parameter

Overriding Shared Server on Clients

If the database is configured for shared server and a particular client requires a dedicated server, you can configure the client to use a dedicated server in one of the following ways: