Configuring Dispatchers in oracle

Configuring Dispatchers
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 dispatcher. It contains these topics:

• Configuring Dispatchers
• Enabling Connection Pooling
• Grouping Services by Dispatcher
• Configuring Clients for Environments Using Both Dedicated Server and Shared Server

Configuring Dispatchers

Shared memory resources for dispatchers, virtual circuits, and shared servers are preconfigured to allow the enabling of shared servers at runtime. Database administrators can start dispatchers and shared servers with the SQL ALTER SYSTEM statement without having to restart the instance to start shared servers. A dispatcher is started automatically on the TCP/IP protocol when shared server mode is turned on and the dispatchers parameterhas not been set. The default configuration for the dispatcher is equivalent to the following DISPATCHERS parameter setting in the database initialization parameter file.

dispatchers="(PROTOCOL=tcp)"

In configurations in which client load is causing a strain on memory and other system resources, database administrators can remedy load issues by starting shared server resources.
Configure the DISPATCHERS parameter if either of the following conditions apply:

• You need to configure another protocol other than TCP/IP.
  You configure an protocol address with one of the following attributes:
  
  • ADDRESS (ADD or ADDR)
  • DESCRIPTION (DES or DESC)
  • PROTOCOL (PRO or PROT)
• You want to configure one or more of the optional dispatcher attributes:
  
  • CONNECTIONS (CON or CONN)
  • DISPATCHERS (DIS or DISP)
  • LISTENER (LIS or LIST)
  • MULTIPLEX (MUL or MULT)
  • POOL (POO)
  • SERVICE (SER or SERV)
  • SESSIONS (SES or SESS)
  • TICKS (TIC or TICK)

After setting this parameter, you do not need to restart the instance. You can alter dispatchers configurations with the SQL statement ALTER SYSTEM.

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:

• CONNECTIONS (CON or CONN)
• SESSIONS (SES or SESS)
• TICKS (TIC or TICK)

Consider a system that can support 950 connections for each process and has:

• 4000 users concurrently connected through TCP/IP
• 2,500 sessions concurrently connected through TCP/IP with SSL

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

DISPATCHERS="(PROTOCOL=tcp)(DISPATCHERS=5)"
DISPATCHERS="(PROTOCOL=tcps)(DISPATCHERS=3)"

Connection pooling can allow each dispatcher to handle more than 950 sessions. For example, suppose that clients are idle most of the time and one dispatcher can route requests and responses for 4000 TCP/IP sessions, or 2,500 TCP/IP with SSL sessions. The following configuration reduces the number of dispatchers required to one for each protocol and allows the dispatchers to be more fully utilized:

DISPATCHERS="(PROTOCOL=tcp)(DISPATCHERS=1)(POOL=on)(TICK=1) (CONNECTIONS=950)(SESSIONS=4000)" 
 
DISPATCHERS="(PROTOCOL=tcps)(DISPATCHERS=1)(POOL=on)(TICK=1) 
(CONNECTIONS=950)(SESSIONS=2500)"
 

The DISPATCHERS and CONNECTIONS attributes do not have to be specified, since the default for DISPATCHERS is 1 and the default for CONNECTIONS is the maximum number of connections for each process, which is operating system dependent.




Source/Reference : http://www.stanford.edu/dept/itss/docs/oracle/10g/network.101/b10775/dispatcher.htm

Dedicated and Shared Server Processes

 

Dedicated and Shared Server Processes Oracle Database creates server processes to handle the requests of user processes connected to an instance. A server process can be either of the following:

• A dedicated server process, which services only one user process
• A shared server process, which can service multiple user processes

Your database is always enabled to allow dedicated server processes, but you must specifically configure and enable shared server by setting one or more initialization parameters.

Dedicated Server Processes

Figure 5-1, "Oracle Database Dedicated Server Processes" illustrates how dedicated server processes work. In this diagram two user processes are connected to the database through dedicated server processes.
In general, it is better to be connected through a dispatcher and use a shared server process. This is illustrated in Figure 5-2, "Oracle Database Shared Server Processes". A shared server process can be more efficient because it keeps the number of processes required for the running instance low.
In the following situations, however, users and administrators should explicitly connect to an instance using a dedicated server process:

• To submit a batch job (for example, when a job can allow little or no idle time for the server process)
• To use Recovery Manager (RMAN) to back up, restore, or recover a database

To request a dedicated server connection when Oracle Database is configured for shared server, users must connect using a net service name that is configured to use a dedicated server. Specifically, the net service name value should include the SERVER=DEDICATED clause in the connect descriptor.

Shared Server Processes

Consider an order entry system with dedicated server processes. A customer phones the order desk and places an order, and the clerk taking the call enters the order into the database. For most of the transaction, the clerk is on the telephone talking to the customer. A server process is not needed during this time, so the server process dedicated to the clerk's user process remains idle. The system is slower for other clerks entering orders, because the idle server process is holding system resources.

 

In a shared server configuration, client user processes connect to a dispatcher. The dispatcher can support multiple client connections concurrently. Each client connection is bound to a virtual circuit, which 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 process 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 shared server architecture over the dedicated server model is the reduction of system resources, enabling the support of an increased number of users.

For even better resource management, shared server can be configured for connection pooling. Connection pooling lets a dispatcher support more users by enabling the database server to time-out protocol connections and to use those connections to service an active session. Further, shared server can be configured for session multiplexing, which combines multiple sessions for transmission over a single network connection in order to conserve the operating system's resources.

Shared server architecture requires Oracle Net Services. User processes targeting the shared server must connect through Oracle Net Services, even if they are on the same machine as the Oracle Database instance.

Source : http://download.oracle.com/docs/cd/E11882_01/server.112/e17120/manproc001.htm#i1006182

Dispatcher  :

A process that enables many clients to connect to the same server without the need for a dedicated server process for each client. A dispatcher handles and directs multiple incoming network session requests to shared server processes.


Glossary : http://www.stanford.edu/dept/itss/docs/oracle/10g/network.101/b10775/glossary.htm#i998494