DB2 Process Model

從接到應用程式的請求開始，DB2就由一連串的agent(又稱EDU, Engine Dispatchable Units)協同作業，完成使用者的請求。9.5版以前，除了Windows是使用Thread model外，Unix和Linux都是使用Process model來建立這些agent，較耗費系統資源。9.5版以後，所有的agent統一使用Thread model。

如下圖所示，依據使用的Protocol不同，每一個Instance都會有一個相對應的Listener來等候使用者的請求，Listener有下列三種

• db2ipccm：處理來自Local Client的請求，當client與server位於同一個OS image，可以使用IPC的 protocol與此Listener溝通
• db2tcpcm：處理遠端Client的請求，當client 與server位於不同OS image時，使用TCP/IP與此Listener溝通
• db2tcpdm：處理DB2的 Discovery工具所發出的請求，DB2有個Discovery工具可以找尋遠端的Instance中，有那些資料庫可以使用。這類的請求由此Listener處理

Listener接受到請求後，會指定一個coordinator agent(db2agent)給該應用程式連線，被assign的db2agent就在DB2中，擔任應用程式的代理人，負責與應用程式溝通，處理應用程式的請求。若在一個Partitioned的資料庫環境，或INTRA_PARALLEL參數設為Yes時，coordinator agent會再把工作交代給 subagent來處理，coordinator agent的角色就變成協調這些subagent完成工作。

如果Access Plan Manager分析結果產生的 Access Plan表示需要進行Prefetch，coordinator agent會送 prefetch的請求到 Prefetch Queue。每個資料庫都有一個Prefetcher，prefetcher從Queue中取得請求後，會把資料由Disk讀取到Bufferpool中。一但資料存在Bufferpool後，coordinator就可以依據應用程式的需求更新資料，更新的資料會暫存在bufferpool中，直到page cleaner將其再寫回Disk。

除此之外，每個應用程式所發出的交易都會由 logger這個agent寫入 transaction log，以備recovery之需。

下圖展示每個agent作用的範圍

接下來介紹db2相關的process。如前所述，9.5版以後 agent是採用thread model，所有的agent都成為依附在主 process下的一個thread，如此一來可大幅減少

Process名稱	描述	適用平台
db2acd	為autonomic computing的 daemon，用來處理client端與automatic相關的工作，如healther monitor、automatic maintenance utilities等。health-monitor process以一個DB2 fenced mode的process執行，在Windows環境，以db2fmp的方式呈現	只限Linux及Unix
db2ckpwd	在DB2 Server端檢驗使用者的ID/Password	只限Linux及Unix
db2fmcd	預設的fault monitor coordinator daemon，每一個實體的機器會有一個	只限Unix
db2fmd	預設的monitor daemon，每個DB2的instance都有一個fault monitor。這個daemon會受 db2fmcd所監控，若把這個process殺掉，db2fmcd會再把這個process叫起來	只限Unix
db2fmp	在DB2的firewall外，在DB2 server上執行user的code。每個db2fmp基本上都是獨立的process，不過對於某些種類的 runtime，可以用multithread的方式執行	所有LUW平台
db2sysc	DB2 System Controller引擎。在DB2 9.5中，每個partition中只會有一個db2sysc引擎 process，所有的EDU(Engine Dispathcable Unit)都會以一個Thread的形式，掛在這個process下。一但這個process停止了，DB2 server就無法作用了。 (p.s. 在Windows平台中，這個process名稱為 db2syscs)	所有LUW平台
db2vend	Fenced vendor process，這是在DB2 9.5版後才引進。在Threaded的引擎下，DB2無法讓vendor的code更改它的signal mask、啟動新的thread或破壞agent的stack。所以所有的vendor code都是獨立於DB2 engine外，在這個process執行	只限Linux及Unix
db2wdog	DB2 watchdog. 這個process是db2sysc的 parent process，負責下列internal事項   - 當db2sysc不正常結束時，清除IPC資源   - 產生 db2fmp及 health-monitor process。當這些process不正常結束時，清除該db2fmp佔用的系統資源，若需要重啟health monitor，也會進行重啟動作	只限Linux及Unix