Shared Server -- Part I

This is the first of my three-part series dealing with Shared servers: Today an organization can have hundreds or thousands of users connecting to their databases. The traditional dedicated server model maps each user to a dedicated process running on the database server. Each dedicated server process requires memory and as the number of users increase, there is a linear increase in the demand for memory. So, there is a definite possibility that, as the number of users connecting, go up, there will come a point where the system will be unable to connect any more users( the proverbial last straw on the camel’s back). Besides, if we have lots of clients connecting/disconnecting, thereby generating a lot of churn, a large amount of resources—CPU and memory—will end up being dedicated to creating a connection and subsequently deleting it. It is precisely these issues that are addressed by the use of a shared server, previously known as multi-threaded server.

A shared server process allows a single server process to service several clients, based on the premise that usually in an OLTP environment, a user is more often than not, reading and editing data on the screen than actually executing a DML. What this means is that, there will be chunks of time when the dedicated server process, dedicated to a particular client will be sitting idle. It is this idleness that is exploited by the shared server process in servicing several clients together. Several advantages accrue as a result of using shared server, most notably:

1. Fewer server processes can handle many more clients, thereby immediately reducing memory demand.
2. Less Churn – as server processes are no longer created/deleted with connection/disconnection of a client.
3. Server processes are utilized more efficiently, as idle time is drastically cut down.

So, although shared servers have certain obvious advantages over dedicated servers, there is some clear trade-offs as well:

The use of a shared server is tied to the assumption that the connecting client will use only a small fraction of his/her time executing queries or ‘talking’ to the database, so that the rest of the time can be used to do work for other clients. The more active a client is, the greater the number of shared server processes have to be created and if the number of clients and their quantum of activity keeps on increasing, then there will come a point where the entire concept of shared server will become meaningless.

While shared server does reduce the demand for memory, it is in no way going to improve performance.

At best, the drop in performance may not be noticed by the users, if they are using a lot of think time, at worst, it has the potential to become a DBA’s nightmare.

Shared servers do not support the use of RMAN. So, if you are going to use RMAN, then you have to use a separate dedicated server connection as well.

The implementation of shared server is predicated on the fact that to enable one connection to be serviced by two or more processes, session specific memory has to be moved to a commonly accessible location. In this post, I will just touch upon the memory structure required for a shared server:

As we know, every connection to an oracle database has some session specific memory tied to it. This memory is sometime referred to as the User Global Area (UGA). The UGA will hold session specific items, bind variable values, and PL/SQL variables. Apart from this the UGA will also hold the sort area.

In a dedicated server process, the UGA is stored in the Program Global Area (PGA). The PGA is a private area for each individual process. However, in the case of a Shared server, the UGA is stored either in the large pool (if it has been configured) or the shared pool.

The rationale for moving the UGA into a shared area is very clear: any shared server process may be called upon to process a SQL statement of the client, so every shared server process needs access to each client’s session state.

While the shared server process does not affect the total amount of memory used for session-specific data, it does move the memory of the individual user server processes into a common memory space accessible to all processes. Any memory savings that come about by the use of shared server process is simply through the reduction in the number of processes that you need to run at any given time.