As we all know, there are two Connection Methods in Oracle: client and server. The Shared Server method is dedicated server. Each has its own advantages and disadvantages and has its own purposes. No one will replace the other. The following describes the two methods extracted from the concepts document.
First, let's take a look at the Shared Server
Shared Server Architecture
Shared Server Architecture eliminates the need for a dedicated server process for each connection. a dispatcher directs multiple incoming Network Session requests to a pool of Shared Server Processes. an idle Shared Server process from a shared pool of server processes picks up a request from a common queue, which means a small number of shared servers can perform the same amount of processing as includedicated servers.
Also, because the amount of memory required for each user is relatively small, less memory and process management are required, and more users can be supported.
A number of different processes are needed in a shared server system:
■ A network listener process that connects the user processes to dispatchers or dedicated servers (the listener process is part of Oracle Net Services, not Oracle ).
■ One or more dispatcher Processes
■ One or more Shared Server Processes
When an instance starts, the network listener process opens and establishes a communication pathway through which users connect to Oracle. then, Each dispatcher process gives the listener process an address at which the dispatcher listens for connection requests. at least one Dispatcher process must be configured and started for each network protocol that the database clients will use.
This involves two other concepts: Request queue (one) and response queue (one or more)
A request from a user is a single program interface call that is part of the user's SQL statement. when a user makes a call, its dispatcher places the request on the Request queue, where it is picked up by the next available shared server process.
The request queue is in the SGA and is common to all dispatcher processes of an instance. the Shared Server Processes check the Common Request queue for new requests, picking up new requests on a first-in-first-out basis. one Shared Server process picks up one request in the queue and makes all necessary cballs to the database
To complete that request.
When the server completes the request, it places the response on the calling dispatcher's response queue. each dispatcher has its own response queue in the SGA. the dispatcher then returns the completed request to the appropriate user process.
To sum up, when using the shared server configuration method, when a connection request is initiated from the client, the server listener first listens to the request and then judges the connection method of the request, if Shared Server is used, this user request is forwarded to a dispatcher with a lighter load. a dispatcher can be connected to multiple users. Next, all the requests sent by the user will be sent to the Request queue by the dispatcher. Other Shared Server processes these requests. After processing, the results will be placed in the response queue of the corresponding dispatcher, in this case, the dispatcher retrieves the result from their respective response queue and returns it to each user.
Of course, if the listener finds that a user's connection request is dedicated, it will not do so. Instead, it starts a dedicated server process and connects the user to the process.
Note: The listener process is not part of an Oracle instance; rather, it is part of the networking processes that work with Oracle.
In addition, Oracle automatically adjusts the number of shared server processes.
Oracle dynamically adjusts the number of shared server processes based on the length of the Request queue. the number of shared server processes that can be created ranges between the values of the initialization parameters shared_servers and Max _ shared_servers.
Since shared server process has such advantages, there are also corresponding restrictions.
Certain administrative activities cannot be specified med while connected to a dispatcher process, including shutting down or starting an instance and media recovery. an error message is issued if you attempt to perform these activities while connected to a dispatcher process.
========================================================== ========================================================== =
Dedicated server configuration
The user and server processes are separate, distinct processes. the separate server process created on behalf of each user process is called a dedicated server process (orshadow process), because this server process acts only on behalf of the associated user process.
This configuration maintains a one-to-one ratio between the number of user processes and server processes. even when the user is not actively making a database Request, the dedicated server process remains (though it is inactive and can be paged out on some operating systems ).
Simply put, a dedicated server process corresponds to a user process. A Shared Server process can serve multiple user processes. In other aspects, dedicated server process and Shared Server process have almost the same functions.
========================================================== ========================================================== =
Another point is that the two methods are not mutually exclusive. They can coexist in the same environment. You can set the connection request mode in the tnsnames. ora file (it seems to be a server parameter ).
In Shared Server mode, the related information of each user is not stored in PGA, but in SGA. (The reason is simple, because each user request is not necessarily processed by the Shared Server, and each Shared Server may process requests from different users, therefore, the user-related information must be stored in a place that can be accessed by all sahred server processes)
In dedicated server mode, the relevant information of each user is stored in the PGA corresponding to each dedicated server process.