Oracle Tips by Burleson

10g Grid Computing with RAC
Real Application Cluster Architecture

Shared Server Configuration

Oracle RAC Instance can be configured both as shared server and as dedicated server. In shared server architecture, the listener assigns each new client session to one of the dispatchers. As the user makes requests, the dispatcher sends the request to the shared server. It is also possible that a different set of shared servers are utilized for a given user session. The dispatchers act as the coordinating agents between the user sessions and the shared servers.

A dispatcher is capable of supporting 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 the client connection requests and replies.

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. In this way, a small number of server processes are able to service a large number of clients or users. This method also supports an increased number of users with less system resources.

Note that not all applications are certified to use shared servers, but that server-side load balancing in a RAC may benefit from using shared servers.

As seen in Fig. 4.10, the listener communicates with the dispatchers on behalf of the user or client sessions. Once the user sessions establish connectivity with dispatchers, the shared servers service them.

Figure 4.10 Shared Server Architecture

Prior to the release of Oracle Database 10g, you needed to set up at least one dispatcher for the shared server configuration to be enabled. You normally needed to set the dispatchers initialization parameter to configure the information about dispatchers.

With Oracle Database 10g, even without specifying a dispatcher with the dispatcher’s parameter, you can enable shared server by setting shared_servers to a nonzero value. The default behavior is that Oracle creates one dispatcher for the TCP protocol automatically. This way, it is easier to configure a shared server environment.

The equivalent dispatcher’s initialization parameter for this configuration would be:

DISPATCHERS="(PROTOCOL=tcp)"

When you need to use shared servers while the system is running, you can simply set the dynamic shared_servers initialization parameter to a value greater than zero with an ALTER SYSTEM command.

As with other parameters, you can change just the current instance with this command and, if you are using an SPFILE, you can change the parameter for future instances as well. For example, to activate three shared servers in the current instance and the SPFILE, enter this command:

SQL> ALTER SYSTEM SET SHARED_SERVERS=3 SCOPE=BOTH;

There are several other parameters that can be set in the shared server environment, but they are not required. Once you set shared_servers, your system will be running in shared server mode.

When you need to configure another protocol other than TCP/IP, configure a protocol address with one of the following attributes: ADDRESS, DESCRIPTION, or PROTOCOL.

Parameters with the prefix MTS are now obsolete. This means that if you try to start an instance using these parameters, you will receive the following error: “ORA-25138: <parameter> initialization parameter has been made obsolete “

Even if you try to set mts_servers during the runtime of an instance:

SQL> ALTER SYSTEM SET MTS_SERVERS = 2;
ALTER SYSTEM SET MTS_SERVERS = 2
*
ERROR at line 1:
ORA-25138: MTS_SERVERS initialization parameter has been made obsolete

All the replacement parameters listed in the table are dynamic, meaning that you can change the values while the instance is running.  The following Table shows the replaced parameters.

Table 4.3 Oracle 10g Replacement Parameters

In the case of the dispatcher’s parameter, the results of the change will depend on which attributes you modify. Since several of the attributes affect the network session layer when a dispatcher is started, they cannot be changed for dispatchers already started. These attributes are protocol, address, description, presentation, connections, sessions, ticks, and multiplex.

You can dynamically modify the other attributes (listener and service) and affect existing as well as new dispatchers of the same configuration.

There is a new view, v$dispatcher_config, that shows more information about existing dispatchers. This view displays information about the dispatcher configurations, including attributes that were not specified and were given a default value. The column CONF_INDX in v$dispatcher_config can be joined to the conf_indx column in v$dispatcher to see all of the detailed information about a given dispatcher. This information helps you to make more informed decisions on what attributes to modify and helps determine if you need to add or remove dispatchers.

For example, to get service and other details about dispatchers, use the following query:

SQL> select name, dispatchers, substr(service,1,20) service, idle, busy
from v$dispatcher,v$dispatcher_config
SEE CODE DEPOT FOR FULL SCRIPT
 
NAME DISPATCHERS SERVICE             IDLE     BUSY
---- ----------- ------------- ---------- --------
D000           1 LONDBXDB         1641097        8