The server processes shown in the diagram arededicated; they serve only one client process. So, if an application has 1,000 clients, the Oracle instance will have 1,000 corresponding server processes. Each server process uses system resources such as the memory and the CPU. Scaling to large user populations can consume a lot of system resources. To support the ever-increasing demand for scalability, Oracle introduced the Multi-Threaded Server (MTS) in Oracle7, known as theshared server since Oracle9i.
Shared servers allow the Oracle instance to share a set of server processes across a larger group of users. Instead of each client connecting to and using a dedicated server, the clients use shared servers, which can significantly reduce the overall resource requirements for serving large numbers of users.
In many systems there are times when the clients aren’t actively using their server process, such as when users are reading and absorbing data retrieved from the data-base. When a client is not using its server process in thededicated model, that server Figure 3-6. Connecting with the Oracle Net Listener
74 | Chapter 3: Installing and Running Oracle
process still has a hold on system resources even though it isn’t doing any useful work. In theshared server model, the shared server can use the resources of an inac-tive client to do work for another client process.
You don’t have to make a mutually exclusive choice between shared server pro-cesses and dedicated server propro-cesses for an Oracle instance. Oracle can mix and match dedicated and shared servers, and clients can connect to one or the other. The choice is based on your Oracle Net configuration files. In the configuration files there will be one service name that leads the client to a dedicated server, and another for connecting via shared servers. The Oracle Net manuals provide the specific syntax for this configuration.
The type of server process a client is using is transparent to the client. From a client perspective, the multithreading or sharing of server processes happens “under the covers,” on the database server. The same Listener handles dedicated and multi-threaded connection requests.
The steps the Listener takes in establishing a shared server connection are a little different and involve some additional background processes for the instance dis-patchers and the shared servers themselves:
Dispatchers
In the previous description of the Listener, you saw how it forms the connection between a client and server process and then steps out of the way. The client must now be able to depend on a server process that is always available to com-plete the connection. Because a shared server process may be servicing another client, the client connects to a dispatcher, which is always ready to receive any client request. There are separate dispatchers for each network protocol being used (e.g., dispatchers for TCP/IP, etc.). The dispatchers serve as surrogate dedi-cated servers for the clients. Clients directly connect to their dispatchers instead of to a server. The dispatchers accept requests from clients and place them in a request queue, which is a memory structure in the SGA. There is one request queue for each instance.
Shared servers
The shared server processes read from the request queue, process the requests, and place the results in the response queue for the appropriate dispatcher. There is one response queue for each dispatcher. The dispatcher then reads the results from the response queue and sends the information back to the client process.
There is a pool of dispatchers and a pool of shared servers. Oracle starts a certain number of each based on the initialization parameter SHARED_SERVERS that speci-fies the minimum number of shared servers. Oracle can start additional shared servers up to the value of an optionally specified initialization parameter MAX_
SHARED_SERVERS. If Oracle starts additional processes to handle a heavier request load and the load dies down again, Oracle gradually reduces the number of pro-cesses to the floor specified by SHARED_SERVERS.
Accessing a Database | 75 The following steps show how establishing a connection and using shared server processes differ from using a dedicated server process:
1. The client contacts the Listener over the network.
2. The Listener detects an incoming request and, based on the Oracle Net configu-ration, determines that it is for a multithreaded server. Instead of handing the client off to a dedicated server, the Listener hands the client off to a dispatcher for the network protocol the client is using.
3. The Listener introduces the client and the dispatcher by letting each know the other’s network address.
4. Once the client and the dispatcher know where to find each other, they commu-nicate directly. The Listener is no longer required. The client sends each work request directly to the dispatcher.
5. The dispatcher places the client’s request in the request queue in the SGA.
6. The next available shared server process reads the request from the request queue and does the work.
7. The shared server places the results for the client’s request in the response queue for the dispatcher that originally submitted the request.
8. The dispatcher reads the results from its queue.
9. The dispatcher sends the results to the client.
Figure 3-7 illustrates the steps for using the shared servers. Network traffic appears as dotted lines.
Figure 3-7. Connecting with the Oracle Net Listener (shared servers)
76 | Chapter 3: Installing and Running Oracle
Session memory for shared server processes versus dedicated server processes
There is a concept in Oracle known assession memoryorstate. State information is basically data that describes the current status of a session in Oracle. For example, state information contains information about the SQL statements executed by the session. When youuse a dedicated server, this state is stored in the private memory used by the dedicated server. This works out well because the dedicated server works with only one client. The term for this private memory is the Program Global Area (PGA).
If you’re using the shared servers, however, any server can work on behalf of a spe-cific client. The session state cannot be stored in the PGA of the shared server process. All servers must be able to access the session state because the session can migrate between different shared servers. For this reason, Oracle places this state information in the System Global Area (SGA).
All servers can read from the SGA. Putting the state information in the SGA allows a session and its state to move from one shared server to another for processing differ-ent requests. The server that picks up the request from the request queue simply reads the session state from the SGA, updates the state as needed for processing, and puts it back in the SGA when processing has finished.
The request and response queues, as well as the session state, require additional memory in the SGA, so in older Oracle releases, youwould allocate more memory manually if you were using shared servers. By default, the memory for the shared server session state comes from the shared pool. Alternatively, youcould also config-ure something called thelarge poolas a separate area of memory for shared servers.
(We introduced the large pool in Chapter 2 in the “Memory Structures for an Instance” section.) Using the large pool memory avoided the overhead of coordinat-ing memory usage with the shared SQL, dictionary cachcoordinat-ing, and other functions of the shared pool. This allowed memory management from the large pool and avoided competing with other subsystems for space in and access to the shared pool. Since Oracle Database 10g, shared memory is automatically managed by default. Oracle Database 11gintroduced automated memory management of the SGA and PGA size by default when you set the MEMORY_TARGET initialization parameter.
Data dictionary information about the shared server
The data dictionary, which we introduced in Chapter 2, also contains information about the operation of the MTS in the following views:
V$SHARED_SERVER_MONITOR
This view contains dynamic information about the shared servers, such as high-water marks for connections and how many shared servers have been started and stopped in response to load variations.