Oracle Database - shared server architecture


Oracle's shared server architecture increases the scalability of applications and the number of clients that can be simultaneously connected to the database. The shared server architecture also enables existing applications to scale up without making any changes to the application itself.

When using shared server, clients do not communicate directly with a database's server process—a database process that handles a client's requests on behalf of a database. Instead, client requests are routed to one or more dispatchers. The dispatchers place the client requests on a common queue. An idle shared server from the shared pool of server processes picks up and processes a request from the queue. This means a small pool of server processes can serve a large number of clients.

Basic difference between the shared and dedicated server

The following two figures show the basic difference between the shared server connection model and the traditional dedicated server connection model. In the shared server model, a dispatcher can support multiple client connections concurrently. In the dedicated server model, there is one server process for each client. Each time a connection request is received, a server process is started and dedicated to that connection until completed. This introduces a processing delay.

Shared server is ideal in configurations with a large number of connections because it reduces the server's memory requirements. Shared server is well suited for both Internet and intranet environments.

Shared servers vs dedicated servers considerations

Using shared servers reduces the number of processes and the amount of memory consumed on the database host. Shared servers are beneficial for databases where there are many OLTP users performing intermittent transactions.

Using shared servers rather than dedicated servers is also generally better for systems that have a high connection rate to the database. With shared servers, when a connect request is received, a dispatcher is available to handle concurrent connection requests. With dedicated servers, however, a connection-specific dedicated server is sequentially initialized for each connection request.

Performance of certain database features can improve when a shared server architecture is used, and performance of certain database features can degrade slightly when a shared server architecture is used.

For example, a session can be prevented from migrating to another shared server while parallel execution is active (then not good for a datawarehouse database)

A session can remain nonmigratable even after a request from the client has been processed, because not all the user information has been stored in the UGA. If a server were to process the request from the client, then the part of the user state that was not stored in the UGA would be inaccessible. To avoid this situation, individual shared servers often need to remain bound to a user session.

When using some features, you may need to configure more shared servers, because some servers might be bound to sessions for an excessive amount of time.

Documentation / Reference

Powered by ComboStrap