I am summarizing Dedicated/Shared Server Architecture information that help DBA to distinguish between them and use as per requirement.
User Sessions: Dedicated Server
With dedicated server processes, there is a one-to-one ratio of server processes to user processes. Each server process uses system resources, including CPU cycles and memory.
In a heavily loaded system, the memory and CPU resources that are used by dedicated server processes can be prohibitive and can negatively affect the system’s scalability. If your system is being negatively affected by the resource demands of the dedicated server architecture, you have the following options:
- Increasing system resources by adding more memory and additional CPU capability
- Using the Oracle Shared Server architecture
User Sessions: Shared Servers
Each service that participates in the shared server architecture has at least one dispatcher process (and usually more). When a connection request arrives, the listener does not spawn a dedicated server process. Instead, the listener maintains a list of dispatchers that are available for each service name, along with the connection load (number of concurrent connections) for each dispatcher.
Connection requests are routed to the lightest loaded dispatcher that is servicing a given service name. Users remain connected to the same dispatcher for the duration of a session.
Unlike dedicated server processes, a single dispatcher can manage hundreds of user sessions.
Dispatchers do not actually handle the work of user requests. Instead, they pass user requests to a common queue located in the shared pool portion of the SGA.
Shared server processes take over most of the work of dedicated server processes, pulling requests from the queue and processing them until they are complete.
Because a single user session may have requests processed by multiple shared server processes, most of the memory structures that are usually stored in the PGA must be in a shared memory location (by default, in the shared pool). However, if the large pool is configured or if SGA_TARGET is set for automatic memory management, these memory structures are stored in the large pool portion of the SGA.
Shared Server: Connection Pooling
The connection pooling feature enables the database server to time out an idle session and use the connection to service an active session. The idle logical session remains open, and the physical connection is automatically reestablished when the next request comes from that session. Therefore, Web applications can allow larger numbers of concurrent users to be accommodated with existing hardware. Connection pooling is configurable through the shared server.
When Not to Use a Shared Server
The Oracle Shared Server architecture is an efficient process and memory use model, but it is not appropriate for all connections. Because of the common request queue and the fact that many users may share a dispatcher response queue, shared servers do not perform well with operations that must deal with large sets of data, such as warehouse queries or batch processing.
Backup and recovery sessions that use Oracle Recovery Manager also deal with very large data sets and must make use of dedicated connections.
Many administration tasks must not (and cannot) be performed by using shared server connections. These include starting up and shutting down the instance, creating tablespaces and data files, maintaining indexes and tables, analyzing statistics, and many other tasks that are commonly performed by the DBA. All DBA sessions must choose dedicated servers.
