Shared server mode and configuration for Oracle

One, the shared server mode work mechanism:

Shared server mode (also known as the MTS Multi-threaded server):

After the database is started, there are two more processes than the dedicated server mode, one is the dispatch process (dispatcher) and the other is the shared server process. Requests from the client are dispatcher accepted, and dispatcher is placed in the request queue. The idle server process starts processing requests in the queue according to the request queue. The processed results are placed in the response queue. Finally, the final result is returned to the client by dispatcher.

In shared server mode, after the client listens for a connection to the dispatcher, dispatcher randomly assigns a port, at which point the client disconnects and listens for connections through the assigned port and dispatcher. The connection with the listener is transient.

Compared to the dedicated server mode, server process UGA in the SGA, while the dedicated server mode UGA in the PGA, in the shared server mode if Large_pool_size is set, the user's UGA will be in Large_pool. MTS reduced memory is actually the memory required for each user to connect to the operating system process in the dedicated server mode, and the shared server model reduces the amount of memory needed to build the server process because it limits the number of server process processes. At the same time, when the concurrent volume is large, it does not need frequent creation and deletion process, reduces the corresponding overhead and increases the concurrent quantity. Therefore, the shared server model is suitable for high concurrency and small processing business systems.

However, compared to the dedicated server mode, the shared server model also has a big problem:

1 The code path for a shared server is longer than a dedicated server, so it is inherently slower than a dedicated server.
2 There is the possibility of an artificial deadlock, because it is serial and whenever a connection is blocked, all users on the server process are blocked and most likely to deadlock.
3 There is a possibility of an exclusive transaction, because if a session is running for a long time, it exclusively shares resources, and other users can only wait, while the dedicated server, each client, is a session.
4 the Shared server mode restricts certain database features, such as the inability to start and close the instance individually, the inability to perform media restores, the use of log Miner, and the Sql_trace (because it is shared rather than the current session).

Because of the problems in the shared server model, and the middleware can realize the effect of the connection pool, it is not common to share the server mode and use the dedicated server mode.

Shared Server Mode configuration

Configuring the shared server mode requires the following parameters to be configured:

Dispatchers: (must be configured) to specify the initial number of scheduled processes for the specified protocol.

Shared_servers: Start several shared server processes initially

Max_shared_servers: How many shared server processes to start

Max_dispatchers: Maximum number of scheduling processes

Shared_server_sessions: The maximum number of sessions a shared server mode can have, and if the number of Shared server mode connections exceeds this setting, the dedicated server mode is used, and note that this value is less than the sessions setting in the database. If this value is not set, all sessions are shared server mode,

Circuits: in Shared server mode Oracle uses virtual circuits to document which client the request originated from, to ensure that the correct client is returned when the request is processed. The circuits setting limits the total number of available loops in the request and response queues. There is only one request queue in the shared server mode, but each dispatcher has its own response queue.

Large_pool_size: Because the UGA is in Large_pool, the appropriate size of the large_pool helps to improve the performance of the system, and it's OK to drop all the UGA on the shared server process.

The following are the specific procedures:

Sys@orcl>show parameter processes

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

Aq_tm_processes integer 0

Db_writer_processes Integer 1

Gcs_server_processes integer 0

Job_queue_processes Integer 10

Log_archive_max_processes Integer 2

Processes integer 300

Sys@orcl>show parameter Sessions

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

Java_max_sessionspace_size integer 0

Java_soft_sessionspace_limit integer 0

License_max_sessions integer 0

license_sessions_warning integer 0

Logmnr_max_persistent_sessions Integer 1

Sessions Integer 335

Shared_server_sessions integer

Sys@orcl>show parameter Dispatcher

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

Dispatchers string (protocol=tcp) (service=orclxd

B

Max_dispatchers integer

Sys@orcl>alter system set dispatchers= ' (PROTOCOL=TCP) (dispatchers=2) (PROTOCOL=IPC) (Dispatchers=1) ';

--Here there are two scheduling processes configured for the TCP protocol, and the IPC protocol configures 1 scheduling processes.

System altered.

Sys@orcl>alter system set max_dispatchers=10;

--Start up to 10 schedulers

System altered.

Sys@orcl>show parameter Shared_server

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

Max_shared_servers integer

Shared_server_sessions integer

Shared_servers Integer 1

Sys@orcl>alter system set shared_servers=10;

System altered.

Sys@orcl>alter system set max_shared_servers=20;

System altered.

Sys@orcl>alter system set shared_server_sessions=100;

System altered.