Oracle 11g DRCP Connection Method-Fundamentals

Learning Oracle is a complex and tedious process. In the face of a vast array of Oracle official materials, new features, MOS materials and a variety of internal knowledge, we always feel overwhelmed. However, this is often the fun we keep, accumulate and pursue.
In Oracle 11g, a third connection method that breaks traditional private/shared connections is presented--database resident Connection Pooling (DRCP). In this article, we will explore this technology.

1. From dedicated server to shared server

The way that Client process connects to Server process is traditionally two ways: dedicated server and shared server. In the process of client connection to Oracle server, the default is to locate the Oracle instance service through the listener Listener listener. Only a child process that is then forked out by the listener requests a server process for remote communication with client process to instance. The different ways of connecting are reflected in how the database instance provides the server process process and how the process is managed after it has accepted the server process request.
Dedicated server mode is also known as private connection, which means that Oracle instance specifically creates a new server process for remote communication with client process. During the entire client process request, the Server process only provides services for that client. The UGA information is also stored in the PGA space of the server process. When the session ends, the client connection is interrupted, and the Server process loses the "presence meaning" and is cleared out, allocating memory for recycling. The dedicated approach is the most common way we use database connections. The advantages of the dedicated approach are obvious in the case of long sessions or front-end applications using connection pooling components.
The dedicated server mode corresponds to the shared server. In this mode, the Oracle instance maintains two types of server process: The distribution process (Dispatcher dxxx) and the shared process (SXXX).

SQL> select addr, pid, spid, username, program from v$process where program like ‘%000%‘;
 
ADDR            PID SPID         USERNAME        PROGRAM

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

6D24BA1C         13 648          SYSTEM          ORACLE.EXE (D000)

6D24C00C         14 1736         SYSTEM          ORACLE.EXE (S000)

When the listener presents the server process allocation request to the DB instance, in Shared server mode, the listener allocates the server process to the distribution process dxxx request. Dxxx allocates a server process for use based on the current idle server situation. When client use is finished, Server Process (SXXX) is not released, but is returned to D000 control. The system also maintains a stable number of sxxx according to the parameter setting.

SQL> show parameter shared_servers
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
max_shared_servers                   integer    

shared_servers                       integer     1

The presence of the Shared server connection mode is related to the development of short sessions, high concurrency, and Internet applications. The cost of creating and recycling the server process is high every time. If the application does not have a middle-tier connection pool, but is highly concurrent to create the server process and quickly recycles, this is a high pressure on the database.
From the present application design and development, the connection pool management has penetrated into the mainstream application system framework, the shared server method is not widely used in practice.

2. Database resident Connection Pooling (DRCP)

If we stand in the perspective of software mode, Shared server essentially wants to implement a pool of connections at the database level. This is achieved on Oracle 11g, where Oracle resident connection pooling (DRCP) is a new feature that allows you to share connections between multiple processes (multi-process) and multi-threaded (multi-threads).
The Shared server has somewhat mitigated the server process Idel and the frequent creation of the destroy server process. However, shared server did not resolve the session data sharing issue. This model is valid when there is a long session for the client, while the other client does not have a large number of sessions required. However, DRCP is a more ideal connection pool model when the time for each request session is short (short sessions) and the database activity requires multiple session interaction.
The new feature of DRCP is mainly about the high number of concurrent connections when the application accesses the database. The DRCP connection pool caches server and session information to provide connection sharing for multiple access applications.
As with shared server, there is an agent (Connection broker) on the DRCP front-end that is responsible for applying the sharing requirements of the middleware connection and for managing connection pooling connections on the DB instance. When application middleware wants the broker to make a connection request, Broker will find the idle connection from the connection pool. When the interaction ends, the Server process is freed back to the connection pool for reuse.
The difference with shared server is that. When the pool of connections in a shared pool is allocated, it is equivalent to dedicated server mode.

3, three ways of connection memory usage

With three connections, Oracle instances, Server process, and memory are used in different ways.

Dedicated Server Mode

When client server requests a connection, the new server process and session information is created. When the connection is interrupted, the Server process and session are all released. Memory allocation is a space that connects the server process and session to be allocated. UGA information is stored in the PGA.

Shared Server Mode

When a request is received from a client server, dispatcher places the request in a common queue. The available server process obtains request information from the queue. When the session is terminated, the corresponding session information is freed. Session information is allocated from the SGA.

DRCP Way

After the client server request, Connection Broker looks for an idle pooled server from the connection pool to be provided to client server. If there is no idle, the Connection broker creates a new connection. If the current connection pool has reached the maximum limit, place the request in the wait queue and wait for the idle server.
When the pooled server is released back to connection pool, the corresponding database resources are freed. The memory requirements of the DRCP are related to the storage pool size and session. Each pooled server has a session message and is stored in the PGA.

The following assignment instance illustrates the situation:

Scenario: An application that requires 400k of space for each session. Each server process corresponds to 4M space. The connection pool size is 100, and the volume of shared server size data is also 100. If there are 5,000 connections.

In Dedicated server mode:
Memory usage=5000* (0.4m+4m) =22GB;

In Shared server mode:
Memory USAGE=5000X0.4M+4MX100=2.5GB; Note that 2G of session information is allocated from the SGA.

In DRCP mode:
Memory usage=100x (4m+0.4m) +5000x35k=615mb. Note: 35K is the amount of memory used to maintain session information.


4. Conclusion

The DRCP model provides a more sophisticated data connection pool solution for front-end applications, based on traditional shared server. From the current information, DRCP to OCI, PHP and other drivers to provide support. Note: Support for JDBC thin and JDBC OCI does not exist yet.

Oracle 11g DRCP Connection Method-Fundamentals