介紹
UNIX和Linux用戶經常檢查運行在服務器上的進程來進行問題分析，並檢查服務器上被消耗的資源。這些信息不僅對解決問題和分析資源的系統管理員有用，而且對於開發高可用性和監視DB2進程以判斷什麼時候執行某種行為（例如數據庫重新啟動）或者執行必要的服務器錯誤恢復（failover）的錯誤恢復腳本都很重要。
如果使用AIX，必須使用ps -ef命令來檢查進程。在Solaris和HP-UX上，ps -ef只為所有的服務器端進程（例如agents、loggers、page cleaners和 prefetchers）顯示db2sysc進程（主要的DB2引擎進程）。如果你使用Solaris或者HP-UX，能使用/usr/ucb/ps -axw命令看到這些進程。這些版本的ps命令都可以在Linux上工作。
在運行DB2 Universal Database客戶端或服務器軟件的計算機上執行這個命令時，可以看到列出了多個DB2進程。本文的目的是說明這些進程並解釋它們是做什麼的以及什麼時候運行。通過閱讀本文你能了解DB2的每個進程，當你看到這些進程時能了解DB2正在執行什麼操作。
注意：在DB2中進程是怎樣執行的對於Windows和Linux、UNIX環境有稍微的不同。在Windows中，只有一個進程（db2sysc），在它下面每個引擎可分配單元（EDU）作為一個線程執行。盡管本文討論進程，但是在Windows環境中應該認為它們是線程。在Windows任務管理器中你能夠看到每個實例的db2sysc進程（db2syscs.exe）。其它的Windows服務/進程也可以顯示，本文我們將解釋它們是什麼。
警告：不要在正常的DB2環境中直接干涉DB2進程。在Linux或UNIX中使用kill -9命令刪除DB2進程可能會引起DB2的不正常的行為。如果刪除進程將導致整個DB2實例停止。本文中的目的是了解這些進程而不是直接維護它們。
為什麼要查看DB2進程
我們的個人經驗已經顯示了這些知識的價值，我們拜訪的客戶也向我們詢問這類信息。看看下面的真實的情況，看看你自己如何檢查系統上運行的DB2進程來解決問題的：
情況1：罕見的緩沖池頁面清除
某個運行電子商務網站並使用DB2作為數據庫服務器的客戶報告說，在一天的多個時段數據庫響應應用程序的時間很長。在這些時期數據庫快照沒有顯示發生了什麼不正常的行為。通過檢查其中一個時段進程的CPU使用率，可以發現I/O清除器（db2pclnr）消耗了超過90％的CPU時間。接下來通過查看I/O清除進程觸發器並適當地調整它們，我們消除了這種情況，該電子商務站點的處理能力提高了50％以上。
情況2：真實的情況
雖然拜訪了某個IBM業務伙伴並執行了一些DB2性能調整，但是我們仍然遇到了普通的響應時間延緩。應用程序列表命令沒有顯示任何在這個時候不正常的進程。在取得DB2快照前，我們查看了DB2服務器上運行的DB2進程，發現db2rebal進程正在運行。在給DMS表空間添加一個容器的時候，該進程用於執行再次數據均衡。該客戶承認那一天它給一個包含40GB表的表空間添加了一個容器。當重新均衡完成後，查詢的響應速度返回到正常情況。
看看通知和診斷日志
管理通知日志和診斷日志（db2diag.log）是系統管理員用於了解數據庫活動和功能的重要工具。正常情況下它們包含DB2進程的信息，下面的例子顯示了一個db2diag.log的條目：
2000-03-06-11.53.18.001160 Instance:myInst Node:000 PID:78121(db2agent (TEST)) TID:352 Appid:*LOCAL.payroll.000306140834lock_manager sqlplrq Probe:111 Database:TEST DIA9999E An internal return code occurred. Report the following:"0xFFFFE10E".
在這個例子中，消息來源的進程ID號是78121。這個進程的名字是db2agent，並且它連接了叫做TEST的數據庫。了解每個進程在做什麼能幫助你了解系統管理通知日志和db2diag.log的內容。
DB2進程的模型
代理
代理可以認為是一個"工作程序"，它執行所有的應用程序需要的數據庫操作。有兩種類型的DB2代理：
◆ 協調程序代理（db2agent）
協調程序代理代表應用程序協調工作，並且使用進程間通訊（interprocess communication，IPC）或者遠程通訊協議與其它的代理通訊。所有的客戶端應用程序連接請求，無論是本地的或遠程的，都會分配一個相應的協調程序代理。
◆ 子代理（db2agntp）
當允許intra_parallel數據庫管理器配置參數時，協調程序代理把數據庫請求分配給子代理（db2agntp）。這些代理為應用程序執行請求。一旦建立了協調程序代理，它就通過協調執行數據庫請求的子代理，代表應用程序處理所有的數據庫請求。
當某個代理或者子代理完成了自己的工作時它就變為空閒的。當某個子代理變為空閒時，它的名字從db2agntp變為db2agnta。
例如：
db2agntp是活動的子代理，它正在為協調程序代理執行工作。這些進程只有允許內部分區並行性（intra-partition parallelism）時才存在。
db2agnta是空閒的子代理，它在過去的某個時候被協調程序代理使用。空閒代理位於代理池中。這些代理對於來自代表客戶端程序的協調程序代理的請求是可用的。可用的代理數量依賴於數據庫管理器的配置參數maxagents和num_poolagents。
本文的後面一部分將講解其它類型的代理（例如並行回復代理，db2agnsc）。下面是顯示DB2進程模型的兩個圖表。
圖1：沒有連接集合的DB2進程模型（對於無分區的數據庫）
圖1中的每個圓圈代表引擎可分配單元（EDU），它是Linux/UNIX平台上的進程，Windows中的線程。
應用程序A（App A）和B（App B）都是運行在DB2服務器上的本地應用程序。當這些應用程序請求一個到數據庫的CONNECT時，db2ipccm監聽進程建立數據庫管理器和應用程序之間的通訊。db2ipccm也使用一個協調程序代理EDU（db2agent）工作，它直接連接客戶端應用程序來建立客戶端應用程序和代理之間的共享內存通訊。一旦建立了該通訊，本地客戶端的應用程序就連接到數據庫了。
應用程序C（App C）是一個遠程應用程序，它位於DB2服務器外的另一台計算機上。遠程客戶端通過db2tcpcm監聽進程建立TCP/IP通訊。接著該db2tcpcm與db2agent一起工作，它成為應用程序的協調程序代理並把連接傳遞到這個代理。在這以後，協調程序代理聯系遠程客戶端應用程序並且連接到數據庫了。
圖2：沒有連接集合的DB2進程模型（對於分區數據庫）
圖2與圖1相似，但可用於分區的數據庫。Node0000和Node0001代表兩個不同的計算機，數據庫的分區分別在它們上面。該進程與它們之間的交互作用與圖1中的相同，但是有一些進程只能用於這樣的環境。例如db2fcmd即快速通訊管理器（Fast Communication Manager）進程，它用於管理不同分區之間的通訊。下一部分的表格更仔細地說明了其它用於分區數據庫的進程。
各個進程
下表按照功能列舉了每個實例、每個數據庫的所有DB2進程。注意下表中的有些進程沒有按字母次序，而是基於功能分組。
表1：每個實例的進程--沒有連接、沒有活動的數據庫
表2：每個實例和每個連接的進程
表3：每個實例和每個活動數據庫的進程
