5.2. Oracle Shared Server Infrastructure
As described in the previous section, you manage client connections quite differently when using Oracle Shared Server as opposed to using a dedicated server. To accommodate the change, several modifications take place inside the internal memory structures of the Oracle Server. The way in which the database and listener interact is also affected when using Oracle Shared Server. It is important to understand these changes when configuring and managing the Oracle Shared Server.
Certain changes are necessary to the memory structures within Oracle to provide the Shared Server capability. Let's see what changes within the Oracle infrastructure are necessary to provide this support.
5.2.1. PGA and SGA Changes When Using Oracle Shared Server
When Oracle Shared Server is configured, Oracle adds two new types of structures to the SGA: request queues and response queues. These structures do not exist in a dedicated server environment. There is one request queue for all dispatchers, but each dispatcher has its own response queue. Therefore, if you have four dispatchers, you will have one request queue and four response queues. The request queue is located in the SGA where the dispatcher places client requests. A Shared Server process executes each request and places the completed request in the dispatchers' response queue.
In a dedicated server environment, each server has a memory segment called a Program Global Area (PGA). The PGA is an area of memory where information about each client session is maintained. This information includes bind variables, cursor information, and the client's sort area. In an Oracle Shared Server environment, this information is moved from the PGA to an area of the SGA called the User Global Area (UGA) . You can configure a special area of the SGA called the Large Pool to accommodate the bulk of the UGA.
NOTE
You will see how to configure the Large Pool in the section "Configuring the Large Pool" later in this chapter.
Figure 5.2 shows how the SGA and PGA structures differ between a dedicated server and an Oracle Shared Server environment.
Each connection being serviced by a dispatcher is bound to a shared memory segment and forms a virtual circuit. The dispatcher uses the shared memory segment to manage communications between the client and the Oracle database. The Oracle Shared Server processes use the virtual circuits to send and receive information to the appropriate dispatcher process.
Figure 5.2. An SGA dedicated server versus Oracle Shared Server
5.2.2. The Role of the Listener in an Oracle Shared Server Environment
The listener plays an important role in the Oracle Shared Server environment. The listener supplies the client with the address of the dispatcher to connect to when a user requests connections to an Oracle Shared Server. The listener maintains a list of dispatchers available from the Oracle Shared Server. The Oracle background process PMON (process monitor) notifies the listener as to which dispatcher is responsible for servicing each virtual circuit. The listener is then aware of the number of connections that the dispatcher is managing. This information allows the listener to take advantage of dispatcher load balancing.
Load balancing allows the listener to make intelligent decisions about which dispatcher to redirect client connections to so that no one dispatcher becomes overburdened. When the listener receives a connection request, it looks at the current connection load for each dispatcher and redirects the client connection request to the least-loaded dispatcher. The listener determines the least-loaded dispatcher for all nodes, if Real Application Clusters (RAC) are being used, followed by the least-loaded instance for the node, and finally by the least-loaded dispatcher for the instance. By doing so, the listener ensures that connections are evenly distributed across dispatchers.
The listener can either redirect the client connection to an available dispatcher or directly hand off the request to the dispatcher. The latter is performed whenever possible and is done typically when the listener and database service exist on the same node. When the listener and database service exist on different nodes, the redirection method is used.
When a client connection terminates, the listener is updated to reflect the change in the number of connections that the dispatcher is handling.
Figure 5.3 illustrates the following steps in the Oracle Shared Server connection process after the database has been started and the dispatcher processes have been started:
The client contacts the Oracle database server after resolving the service name.
The listener validates the Oracle Service Name supplied by the client and hands off or redirects the client connection to the least-busy dispatcher.
The listener sends information back to the client so the client can redirect the connection to the appropriate dispatcher process.
The dispatcher process manages the client server request.
PMON registers connection information with the listener.