Oracle 11g DRCP連線方式——基本原理

 

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

 

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

 

1、 從Dedicated Server到Shared Server

 

Oracle 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的支援還不存在。