詳解Oracle 11g DRCP連接方式的基本原理

學習Oracle是一個復雜、繁瑣的過程。在浩如煙海的Oracle官方資料、新特性、MOS資料和各種Internal知識面前，我們總是覺得力不從心、不知所措。但是，這往往也就是我們不斷堅持、積累和追尋的樂趣。

在Oracle 11g中，提出了突破傳統專用/共享連接的第三種連接方式——Database Resident Connection Pooling（DRCP）。本篇我們一起來探討這項技術。

1、 從Dedicated Server到Shared Server

　　Client Process連接到Server Process的方式，傳統上有兩種方式：Dedicated Server和Shared Server。在Client連入到Oracle Server的過程中，默認是通過監聽器listener監聽器進行Oracle實例服務定位。只有再由監聽器fork出的子進程向Instance請求出一個Server Process與Client Process遠程通信。不同的連接方式，就體現在數據庫實例在接受到Server Process請求后，是怎么樣提供出Server Process進程，以及該進程如何管理的。
Dedicated Server模式也稱為專用連接方式，就是Oracle Instance會專門創建出一個新的Server Process與Client Process進行遠程通信。在整個Client Process請求過程中，Server Process只為該Client提供服務。UGA信息也保存在Server Process的PGA空間中。當會話結束，Client連接中斷，Server Process就失去“存在意義”被清除掉，分配內存回收。Dedicated方式是我們最常使用的數據庫連接方式。在長會話或前端應用使用連接池組件的情況下，Dedicated方式的優勢是很明顯的。
與Dedicated Server模式對應的是Shared Server。在該模式下，Oracle實例會維持兩種Server Process：分發進程（Dispatcher DXXX）和共享進程（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)

當監聽器向數據庫實例提出Server Process分配請求的時候，在Shared Server模式下，監聽器會向分發進程DXXX請求分配Server Process。DXXX會根據當前的空閑Server情況，分配出一個Server Process供使用。當Client使用結束之后，Server Process（SXXX）并不是被釋放，而是重新回到D000管制下。系統也會依據參數設置，維持一個穩定的SXXX數量。

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

shared_servers      integer  1

Shared Server連接模式的出現，是和短會話、高并發的互聯網應用發展相關。每次創建和回收Server Process的成本是很高的。如果應用沒有中間層連接池，而是高并發的創建Server Process并且快速回收，這對于數據庫來說是很高的壓力。
 從現在的應用設計開發看，連接池管理已經滲透入主流應用系統框架，shared server方式實際中應用不是很廣泛。

2、Database Resident Connection Pooling（DRCP） 

如果我們站在軟件模式的角度看，Shared Server本質上也是想實現一種在數據庫層面上的連接池。這點在Oracle 11g上得到了實現，Oracle駐留連接池（DRCP）就是一個允許在多進程（Multi-Process）和多線程（Multi-Threads）之間共享連接的新特性。
Shared server在一定程度上緩解了Server process IDEL和頻繁創建銷毀Server process的問題。但是，Shared Server沒有解決Session數據共享的問題。當存在client需要長時間持有session，同時其他client沒有大量會話要求的時候，這種模型是有效的。但是，在每次請求會話的時間很短（短會話）和數據庫活動需要多次會話交互的時候，DRCP就是更加理想的連接池模型了。
DRCP新特性主要針對的就是應用程序在訪問數據庫時，出現高并發連接數問題。DRCP連接池將Server和Session信息進行緩存，為多個訪問的應用程序提供連接共享。
 同Shared Server一樣，DRCP前端存在一個代理（Connection Broker）,負責應用中間件連接的共享要求，同時負責管理數據庫實例上的連接池連接。當應用中間件想Broker提出連接請求的時候，Broker會從連接池中找出空閑連接。當交互結束后，Server Process被釋放回連接池供重用。
同shared server不同的方面在于。當共享池中連接池被分配出之后，等價于dedicated server方式。

3、三種連接方式的內存使用情況

三種連接方式下，Oracle實例、Server Process和內存使用方式截然不同。

Dedicated Server方式

當Client Server請求連接的時候，全新的Server Process和session信息被創建。當連接中斷，Server Process和Session全部被釋放。內存分配是一個連接要分配Server Process和Session的空間。UGA信息是保存在PGA里的。 

Shared Server方式

當接收到Client Server的請求之后，Dispatcher會將請求放置在一個common隊列中。可用的Server Process就從隊列中獲取請求信息。當終止會話之后，對應的會話信息就被釋放掉。Session信息是從SGA中分配出。

DRCP方式

當Client Server請求之后，Connection Broker從連接池中尋找一個空閑Pooled Server提供給Client Server。如果沒有空閑的，Connection Broker就會創建出一個新的連接。如果當前連接池已經達到最大數量限制，就將請求放置在等待隊列中，等待空閑Server。

當釋放Pooled Server回到Connection Pool的時候，相應的數據庫資源被釋放掉。DRCP的內存要求與存儲池大小和會話有關。每個Pooled Server有一個Session信息，且存儲在PGA中。 

下面一個分配實例，來說明情況： 

場景：一個應用程序，其每個session需要400k的空間。每個Server process對應4M空間。連接池大小為100，共享shared Server大小數據量也是100。如果有5000個連接數。

在Dedicated Server模式下：

Memory Usage=5000*(0.4M+4M)=22GB；

在Shared Server模式下：

Memory Usage=5000×0.4M+4M×100=2.5GB；注意，其中Session信息的2G是從SGA中分配的。 

在DRCP模式下：
Memory Usage=100×（4M+0.4M）+5000×35K=615MB。注意：35K為維護會話信息使用的內存大小。 

4、結論

DRCP模式在傳統的shared server基礎上，為前端應用提供更加成熟的數據連接池解決方案。從目前的資料看，DRCP對OCI、PHP等多種驅動提供了支持。注意：對JDBC Thin和JDBC OCI的支持還不存在。

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持億速云。