DBMS的進程結構和多線索機制

實際應用中，DBMS以及應用程序都必須進入某個具體的操做系統環境。應用程序經過DBMS，DBMS經過OS，與數據庫中的數據打交道。根據三者的關係，通常有下述四種進程組織方案。

 

 DBMS的進程結構

1、N方案：DBMS與應用程序相融合的方案

在這種方案中，N個DB用戶僅需N個進程，DBMS做爲應用程序的子程序被連入應用程序中，成爲應用程序的一部分，所以這種方案也被稱爲連入式方案。

做爲一種子程序技術，N方案對內存的需求量比較大。由於用戶與DBMS功能的融合使得DBMS的代碼段沒法共享，致使內存中保留了DBMS代碼的許多副本。隨着DBMS功能的日興加強，DBMS代碼會不斷擴大，N方案形成的代碼冗餘會使系統性能降低，甚至達到使人沒法忍受的程度。

N方案DBMS實現起來比較簡單，不用考慮用戶進程與DBMS進程間的通訊，所以在用戶數少的小型DBMS中能夠採用此方法。

解決N方案DBMS代碼冗餘的辦法是將圖1中的APi與其DBMS副本分開，讓DBMS的代碼段在內存中被共享，這就引出下面的方案。

2、2N方案：一個DBMS進程對應一個用戶進程

每一個用戶進程均有一個DBMS進程爲之服務，稱這種DBMS進程爲影子進程。在這種方案中，有N個用戶進程就要啓動N個DBMS進程（共2N個進程），所以這種進程結構方案稱爲2N方案。

在這種狀況下，數據庫系統的各個活躍進程都是獨立運行的，所以用戶進程與Shadow進程之間以及各Shadow進程之間都要通訊。

系統的全局管理數據駐留在SGA中，各DBMS進程靠操做系統提供的封鎖原語（信號量）實現同步或實現對SGA的互斥訪問。所以DBMS的這種進程組織方式使進程間總的通訊開銷上升不少。

在2N結構的方案中，操做系統的負擔增大了，主要表如今空間和時間兩個方面。在空間上，雖然各個DBMS進程的代碼段（如UNIX中的正文段）能夠共享，但數據段和棧段的空間仍是各自的，再加上OS要爲多出的N個Shadow進程分配進程控制塊（PCB）等諸多內部空間，所以2N結構對內存的須要量亦是不少。這極易使內存頁面情況變壞，並可能因物理內存遠遠小於各進程虛空間之和而致使進程被操做系統頻繁換入換出，使系統出現顛簸。在時間方面，因爲2N方案進程數目過多，許多CPU時間會白白浪費在進程切換這種昂貴的工做上。顛簸及進程切換的高額開銷使系統性能嚴重降低。

2N方案中增長一個用戶所須要的資源很大，一般增長現三個用戶就須要1MB內存量，再加上操做系統所支持的進程總數有限，致使2N方案不可能支持不少的DBMS用戶，所以它不大適合大量用戶的OLTP應用。

除了每一個用戶進程須要一個DBMS服務進程外，DBMS全局上還要維護若干個後臺服務進程。由這些後臺進程經過SGA完成諸如監控、寫數據庫、預讀、寫日誌、淘汰頁面、死鎖檢測和解除等全局工做。使用後臺進程大大增長了進程間通訊的開銷，而頻繁的進程通訊意味着頻繁的進程切換。少數幾個後臺進程還可能成爲整個系統的瓶頸。

此外，2N方案至少還會碰到數據不在內存時所形成的性能問題和臨界區問題，這裏就再也不詳細討論了。

把多個DBMS進程合爲一個DBMS進程能夠有效解決上述問題，這就是N+1方案。與N+1方案相比 ，2N方案的最大優點是它省掉了DBMS對各數據用戶的多任務調度，而把這個任務交給了操做系統，從而簡化了用戶進程與DBMS的接口。

Oracle 7以前的版本、Ingres和Informix的早期版本使用2N方案（最先的INGRES採用4N方案：每一個用戶進程有3個分別完成不一樣任務的DBMS進程爲之服務）。

3、N+1方案：一個DBMS進程對應全部用戶進程

進程結構的另外一種組織方式是整個DBMS僅使用一個進程，該進程的行爲相似於一個服務器。多個數據庫用戶向Server發消息，以申請數據庫服務。Server要用本身的機制來調度這些申請，以支持一個多任務的數據庫系統。因爲N個用戶僅須要一個DBMS進程，所以稱這種進程結構方案爲N+1方案，這時SGA已不須要了。

因爲要設計本身的多任務處理機制和調度算法，使得N+1方案的DBMS設計在總體上比2N方案要複雜。Server要處理全部用戶的申請，若是調度策略不當或不能使數據庫進程得到較高的優先權，這種方案將致使瓶頸。

另外，N+1方案中要用操做系統級的消息機制以實現多進程向單進程以及單進程向多進程的數據傳送。許多文獻指出消息系統是一種昂貴的設施，大多數操做系統中消息往返一次的開銷是幾千條指令。

這種方案的另外一個優勢是能夠採用多線索技術來實現N+1方案，從而能夠大大提升系統性能，下降系統資源的開銷，簡化DBMS許多部分的設計。線索機制可使得N+1方案能用統一的「線索」思想處理全部的執行流，其中包括DBMS核心的執行流，這將省去全部的後臺進程並能適應系統軟件設計與開發的微內核要求，使DBMS的核心代碼簡明精巧，易於移植。

4、N+M方案：M個DBMS進程對應N個用戶進程

N+M方案採用M個DBMS進程爲N個用戶進程提供服務（通常M<N）.

在該方案中，DBMS進程不負責多任務調度，同時每一個用戶進程也不固定對應某個DBMS進程。用戶的數據庫請求將會被動態的分配給某個DBMS來處理。

DBMS進程的分派由分派程序完成。分派程序能夠是一個單獨的後臺進程，也能夠將其代碼連入用戶進程（APi）中。分派程序經過SGA管理用戶的數據庫請求隊列，並分配某個DBMS進程服務於某個用戶進程。分派程序還應監測整個DBMS的運行情況並根據用戶請求隊列的狀況動態增減DBMS進程的個數。若是用戶增長，則DBMS進程的個數也動太增長，但後者通常總小於前者（即M<N）。

N+M方案基於的指導思想是：用戶進程可能並不老是同時提出數據庫請求以，一個用戶一個DBMS進程方案太浪費，幾個用戶輪流使用一個DBMS服務進程也許會節約一些。

N+M方案是2N方案的一種改進，提升了內存資源的利用率，但它沒有克服2N方案的本質弱點。此外，分派程序給系統增長了開銷並有可能成爲系統的瓶頸，並且DBMS動態增減的開銷亦很大。

多線索DBMS的概念

1、線程的概念

數據庫中的線程的概念源於操做系統中線程的概念。

隨着多處理器系統以及並行計算技術的發展，進程概念進一步劃分爲任務與線程的概念。

UNIX核心中的最關鍵的概念就是進程。進程既是資源分配的最小單位也是運行的最小單位。與一個進程相聯繫的資源有：進程虛擬空間、進程控制塊、數據段、正文段、堆棧段、共享內存、程序計數器、狀態寄存器以及通用寄存器等。進程創建及切換的開銷很大，核心維護每個進程的虛擬空間開銷很大。進程概念在處理微粒度問題時顯得很吃力。出於以上考慮，1988年卡內基-梅隆大學在其研製的多機操做系統MACH中實現了Task和Thread。

他們將進程的概念一分二：Task是申請資源的最小單位，而Thread是調度和運行的最小單位。一個Task中可有多個Thread，這些Thread共享Task全部資源，共同完成一個任務。一個Thread只能存在於某個Task中。在多處理機上，這些Thread可真正的並行執行。UNIX中進程的概念至關於MACH中的只包含一個Thread的Task。

因爲多個線程運行於同一實體中而且共享該實體的全部資源，使得傳統UNIX中屬於某一任務的多個進程以線程的方式並行執行時效率大大提升。

可見，線程的基本概念就是將進程中的程序代碼與進程所佔資源相分離，從而能夠在一個地址空間運行多個指令流。

2、多線索DBMS

數據庫系統中的線索概念借鑑了操做系統中線程的含義：整個DBMS能夠看做是一個Task，當有一個用戶申請數據庫服務時，Task分配至少一個Thread爲之服務，多個Thread並行工做，共享資源。

通常地講，DBMS中線索是DBMS的一個執行流，它服務於整個DBMS系統中的某個用戶；DBMS服務器響應客戶請求是經過爲每一個用戶建立線索來完成的。DBMS的各個線索能在邏輯上並行執行；它們共存在一個進程中，共享DBMS的資源，如數據庫緩衝區和CPU時間；線索是DBMS的調度單位，服務器進程能按必定的調度算法調度用戶請求，因爲調度優化策略是數據庫服務器執行，所以會比操做系統直接對這些請求高度高效得多。

多線索機制能夠減小每一個用戶須要的系統資源，如內存要求，從而能夠增長併發用戶數，提升服務器的運行效率，更好的支持OLTP應用。

3、線索與進程的比較

1.線索比進程佔用較少的資源

進程是程序的動態概念，指正在執行的程序。進程有其自身的程序地址空間，除正文段之外，進程間通常共享彼此資源。線索則是程序中的一串指令流，同一進程內的多個線索共享該進程內的一切資源。所以，線索比進程佔用更少的系統資源，是更小的調度單位，可支持細粒度的並行。

2.線索的調度比較靈活，可控制性強

線索的調度方式比較靈活，能夠實現智能化的高度，提升並行效率。

進程調度由操做系統控制，DBMS無權干涉，並且進程的調度是非智能的，特定的進程會被頻繁掛起。例如，假定一個進程要反覆讀取數據、處理數據並回寫數據，該進程會因等待I/O而被頻繁掛起，效率很低。若是將該進程劃分爲讀、處理、寫3個線索，當其中某個線索被阻塞，其它線索能夠調度運行，效率就會提升。並且，經過合理高度一個進程內的金條併發線索，而使該進程長久的佔用CPU。不管是單處理機仍是多處理機，多線索結構均能提升執行效率。

3.線索切換開銷較小

就進程切換而言，因爲進程的地址空間是私有的，所以進程切換必須保持進程的正文、數據、棧段及地址映射、進程狀態、寄存器值等系統信息，通常須要花費數千條機器指令；而線索因爲共享同一地址空間，所以當切換同一進程內的不一樣線索時，只需保持線索狀態、寄存器值等，因爲切換較少的信息，線索切換的代碼量明顯減小，通常須要數十條指令。

4.線索間通訊方便

UNIX操做系統將進程的地址空間相隔離是爲了不併發進程間的相互干擾，之後爲了支持進程間通訊又前後引入管道、通道、新IPC機制等通訊手段，這些通訊機制或者編程麻煩、不易使用，或者有必定的侷限性、效率不高。同一進程內線索因爲共享地址空間，於是能夠藉助全局變量名的指針來進行通訊，這種通訊簡單直接。不過，因爲線索間能夠互訪數據，所以在利用線索編程就注意保持數據的一致性和完整性。