介紹

UNIX和Linux用戶經(jīng)常檢查運(yùn)行在服務(wù)器上的進(jìn)程來進(jìn)行問題分析，并檢查服務(wù)器上被消耗的資源。這些信息不僅對(duì)解決問題和分析資源的系統(tǒng)治理員有用，而且對(duì)于開發(fā)高可用性和監(jiān)視DB2進(jìn)程以判定什么時(shí)候執(zhí)行某種行為（例如數(shù)據(jù)庫重新啟動(dòng)）或者執(zhí)行必要的服務(wù)器錯(cuò)誤恢復(fù)（failover）的錯(cuò)誤恢復(fù)腳本都很重要。

假如使用AIX，必須使用ps -ef命令來檢查進(jìn)程。在Solaris和HP-UX上，ps -ef只為所有的服務(wù)器端進(jìn)程（例如agents、loggers、page cleaners和 prefetchers）顯示db2sysc進(jìn)程（主要的DB2引擎進(jìn)程）。假如你使用Solaris或者HP-UX，能使用/usr/ucb/ps -axw命令看到這些進(jìn)程。這些版本的ps命令都可以在Linux上工作。

在運(yùn)行DB2 Universal Database客戶端或服務(wù)器軟件的計(jì)算機(jī)上執(zhí)行這個(gè)命令時(shí)，可以看到列出了多個(gè)DB2進(jìn)程。本文的目的是說明這些進(jìn)程并解釋它們是做什么的以及什么時(shí)候運(yùn)行。通過閱讀本文你能了解DB2的每個(gè)進(jìn)程，當(dāng)你看到這些進(jìn)程時(shí)能了解DB2正在執(zhí)行什么操作。

注重：在DB2中進(jìn)程是怎樣執(zhí)行的對(duì)于Windows和Linux、UNIX環(huán)境有稍微的不同。在Windows中，只有一個(gè)進(jìn)程（db2sysc），在它下面每個(gè)引擎可分配單元（EDU）作為一個(gè)線程執(zhí)行。盡管本文討論進(jìn)程，但是在Windows環(huán)境中應(yīng)該認(rèn)為它們是線程。在Windows任務(wù)治理器中你能夠看到每個(gè)實(shí)例的db2sysc進(jìn)程（db2syscs.exe）。其它的Windows服務(wù)/進(jìn)程也可以顯示，本文我們將解釋它們是什么。

警告：不要在正常的DB2環(huán)境中直接干涉DB2進(jìn)程。在Linux或UNIX中使用kill -9命令刪除DB2進(jìn)程可能會(huì)引起DB2的不正常的行為。假如刪除進(jìn)程將導(dǎo)致整個(gè)DB2實(shí)例停止。本文中的目的是了解這些進(jìn)程而不是直接維護(hù)它們。為什么要查看DB2進(jìn)程

我們的個(gè)人經(jīng)驗(yàn)已經(jīng)顯示了這些知識(shí)的價(jià)值，我們拜訪的客戶也向我們?cè)儐栠@類信息。看看下面的真實(shí)的情況，看看你自己如何檢查系統(tǒng)上運(yùn)行的DB2進(jìn)程來解決問題的：

情況1：罕見的緩沖池頁面清除

某個(gè)運(yùn)行電子商務(wù)網(wǎng)站并使用DB2作為數(shù)據(jù)庫服務(wù)器的客戶報(bào)告說，在一天的多個(gè)時(shí)段數(shù)據(jù)庫響應(yīng)應(yīng)用程序的時(shí)間很長(zhǎng)。在這些時(shí)期數(shù)據(jù)庫快照沒有顯示發(fā)生了什么不正常的行為。通過檢查其中一個(gè)時(shí)段進(jìn)程的CPU使用率，可以發(fā)現(xiàn)I/O清除器（db2pclnr）消耗了超過90％的CPU時(shí)間。接下來通過查看I/O清除進(jìn)程觸發(fā)器并適當(dāng)?shù)卣{(diào)整它們，我們消除了這種情況，該電子商務(wù)站點(diǎn)的處理能力提高了50％以上。

情況2：真實(shí)的情況

雖然拜訪了某個(gè)IBM業(yè)務(wù)伙伴并執(zhí)行了一些DB2性能調(diào)整，但是我們?nèi)匀慌龅搅似胀ǖ捻憫?yīng)時(shí)間延緩。應(yīng)用程序列表命令沒有顯示任何在這個(gè)時(shí)候不正常的進(jìn)程。在取得DB2快照前，我們查看了DB2服務(wù)器上運(yùn)行的DB2進(jìn)程，發(fā)現(xiàn)db2rebal進(jìn)程正在運(yùn)行。在給DMS表空間添加一個(gè)容器的時(shí)候，該進(jìn)程用于執(zhí)行再次數(shù)據(jù)均衡。該客戶承認(rèn)那一天它給一個(gè)包含40GB表的表空間添加了一個(gè)容器。當(dāng)重新均衡完成后，查詢的響應(yīng)速度返回到正常情況。

看看通知和診斷日志

治理通知日志和診斷日志（db2diag.log）是系統(tǒng)治理員用于了解數(shù)據(jù)庫活動(dòng)和功能的重要工具。正常情況下它們包含DB2進(jìn)程的信息，下面的例子顯示了一個(gè)db2diag.log的條目：

2000-03-06-11.53.18.001160Instance:myInst　 Node:000PID:78121(db2agent (TEST)) TID:352　Appid:*LOCAL.payroll.000306140834lock_manager　sqlplrqProbe:111　 Database:TESTDIA9999E　An internal return code occurred. Report the following:"0xFFFFE10E".;

在這個(gè)例子中，消息來源的進(jìn)程ID號(hào)是78121。這個(gè)進(jìn)程的名字是db2agent，并且它連接了叫做TEST的數(shù)據(jù)庫。了解每個(gè)進(jìn)程在做什么能幫助你了解系統(tǒng)治理通知日志和db2diag.log的內(nèi)容。DB2進(jìn)程的模型代理代理可以認(rèn)為是一個(gè)"工作程序"，它執(zhí)行所有的應(yīng)用程序需要的數(shù)據(jù)庫操作。有兩種類型的DB2代理：

◆ 協(xié)調(diào)程序代理（db2agent）協(xié)調(diào)程序代理代表應(yīng)用程序協(xié)調(diào)工作，并且使用進(jìn)程間通訊（interprocess communication，IPC）或者遠(yuǎn)程通訊協(xié)議與其它的代理通訊。所有的客戶端應(yīng)用程序連接請(qǐng)求，無論是本地的或遠(yuǎn)程的，都會(huì)分配一個(gè)相應(yīng)的協(xié)調(diào)程序代理。◆ 子代理（db2agntp）當(dāng)答應(yīng)intra_parallel數(shù)據(jù)庫治理器配置參數(shù)時(shí)，協(xié)調(diào)程序代理把數(shù)據(jù)庫請(qǐng)求分配給子代理（db2agntp）。這些代理為應(yīng)用程序執(zhí)行請(qǐng)求。一旦建立了協(xié)調(diào)程序代理，它就通過協(xié)調(diào)執(zhí)行數(shù)據(jù)庫請(qǐng)求的子代理，代表應(yīng)用程序處理所有的數(shù)據(jù)庫請(qǐng)求。當(dāng)某個(gè)代理或者子代理完成了自己的工作時(shí)它就變?yōu)榭臻e的。當(dāng)某個(gè)子代理變?yōu)榭臻e時(shí)，它的名字從db2agntp變?yōu)閐b2agnta。例如：db2agntp是活動(dòng)的子代理，它正在為協(xié)調(diào)程序代理執(zhí)行工作。這些進(jìn)程只有答應(yīng)內(nèi)部分區(qū)并行性（intra-partition parallelism）時(shí)才存在。db2agnta是空閑的子代理，它在過去的某個(gè)時(shí)候被協(xié)調(diào)程序代理使用。空閑代理位于代理池中。這些代理對(duì)于來自代表客戶端程序的協(xié)調(diào)程序代理的請(qǐng)求是可用的。可用的代理數(shù)量依靠于數(shù)據(jù)庫治理器的配置參數(shù)maxagents和num_poolagents。本文的后面一部分將講解其它類型的代理（例如并行回復(fù)代理，db2agnsc）。

下面是顯示DB2進(jìn)程模型的兩個(gè)圖表。

　圖1：沒有連接集合的DB2進(jìn)程模型（對(duì)于無分區(qū)的數(shù)據(jù)庫）

圖1中的每個(gè)圓圈代表引擎可分配單元（EDU），它是Linux/UNIX平臺(tái)上的進(jìn)程，Windows中的線程。

應(yīng)用程序A（App A）和B（App B）都是運(yùn)行在DB2服務(wù)器上的本地應(yīng)用程序。當(dāng)這些應(yīng)用程序請(qǐng)求一個(gè)到數(shù)據(jù)庫的CONNECT時(shí)，db2ipccm監(jiān)聽進(jìn)程建立數(shù)據(jù)庫治理器和應(yīng)用程序之間的通訊。db2ipccm也使用一個(gè)協(xié)調(diào)程序代理EDU（db2agent）工作，它直接連接客戶端應(yīng)用程序來建立客戶端應(yīng)用程序和代理之間的共享內(nèi)存通訊。一旦建立了該通訊，本地客戶端的應(yīng)用程序就連接到數(shù)據(jù)庫了。

應(yīng)用程序C（App C）是一個(gè)遠(yuǎn)程應(yīng)用程序，它位于DB2服務(wù)器外的另一臺(tái)計(jì)算機(jī)上。遠(yuǎn)程客戶端通過db2tcpcm監(jiān)聽進(jìn)程建立TCP/IP通訊。接著該db2tcpcm與db2agent一起工作，它成為應(yīng)用程序的協(xié)調(diào)程序代理并把連接傳遞到這個(gè)代理。在這以后，協(xié)調(diào)程序代理聯(lián)系遠(yuǎn)程客戶端應(yīng)用程序并且連接到數(shù)據(jù)庫了。　

　圖2：沒有連接集合的DB2進(jìn)程模型（對(duì)于分區(qū)數(shù)據(jù)庫）

圖2與圖1相似，但可用于分區(qū)的數(shù)據(jù)庫。Node0000和Node0001代表兩個(gè)不同的計(jì)算機(jī)，數(shù)據(jù)庫的分區(qū)分別在它們上面。該進(jìn)程與它們之間的交互作用與圖1中的相同，但是有一些進(jìn)程只能用于這樣的環(huán)境。例如db2fcmd即快速通訊治理器（Fast Communication Manager）進(jìn)程，它用于治理不同分區(qū)之間的通訊。下一部分的表格更仔細(xì)地說明了其它用于分區(qū)數(shù)據(jù)庫的進(jìn)程。

各個(gè)進(jìn)程

下表按照功能列舉了每個(gè)實(shí)例、每個(gè)數(shù)據(jù)庫的所有DB2進(jìn)程。注重下表中的有些進(jìn)程沒有按字母次序，而是基于功能分組。表1：每個(gè)實(shí)例的進(jìn)程--沒有連接、沒有活動(dòng)的數(shù)據(jù)庫表2：每個(gè)實(shí)例和每個(gè)連接的進(jìn)程

表3：每個(gè)實(shí)例和每個(gè)活動(dòng)數(shù)據(jù)庫的進(jìn)程表4：按功能分類的其它進(jìn)程　　表5：一些常用的執(zhí)行文件　　表6：其它的Windows服務(wù)/進(jìn)程示例下面的例子顯示了在AIX上運(yùn)行ps -ef命令時(shí)可能得到的輸出：在db2start后：

root 49504 1　 0 13:13:07　-　0:00 db2wdogdb2inst1 22142 49180　 0 13:13:10　-　0:00 db2gdsdb2inst1 43072 49180　 0 13:13:17　-　0:00 db2syslogdb2inst1 45294 74134　 0 12:12:43　pts/2　0:00 /usr/bin/kshdb2inst1 49180 49504　 0 13:13:10　-　0:00 db2syscdb2inst1 55920 49180　 0 13:13:19　-　0:00 db2resyncdb2inst1 59012 22142　 0 13:13:19　-　0:00 db2srvlstdb2inst1 60680 49180　 0 13:13:17　-　0:00 db2ipccm數(shù)據(jù)庫治理器配置文件有下面的設(shè)置，他們影響到你最初看到的進(jìn)程：

Max number of existing agents　 (MAXAGENTS) = 200Agent pool size(NUM_POOLAGENTS) = 100(calculated)Initial number of agents in pool　 (NUM_INITAGENTS) = 0;

因?yàn)镹UM_INITAGENTS為0，在db2start時(shí)沒有"db2agent（idle）"進(jìn)程顯示。假如在db2agent前把NUM_INITAGENTS設(shè)置為5，在運(yùn)行db2start后將顯示下面的額外進(jìn)程：db2inst1 35542 59814　 0 16:25:57　-　0:00 db2agent (idle)db2inst1 43096 59814　 0 16:25:57　-　0:00 db2agent (idle)db2inst1 49628 59814　 0 16:25:57　-　0:00 db2agent (idle)db2inst1 58170 59814　 0 16:25:57　-　0:00 db2agent (idle)db2inst1 64012 59814　 0 16:25:57　-　0:00 db2agent (idle)　

　在連接到數(shù)據(jù)庫SAMPLE后（NUM_INITAGENTS仍然為0）：root 49504 1　 0 13:13:07-　0:00 db2wdogdb2inst1 25844 35124　 0 16:04:50-　0:00 db2pfchrdb2inst1 35124 65638　 0 16:04:17-　0:00 db2gdsdb2inst1 35540 35124　 0 16:04:50-　0:00 db2loggr (SAMPLE)db2inst1 41940 65638　 0 16:04:19-　0:00 db2resyncdb2inst1 45058 35124　 0 16:04:50-　0:00 db2pfchrdb2inst1 49300 35124　 0 16:04:19-　0:00 db2srvlstdb2inst1 49626 35124　 0 16:04:50-　0:00 db2dlock (SAMPLE)db2inst1 55852 65638　 0 16:04:17-　0:00 db2ipccmdb2inst1 58168 35124　 0 16:04:50-　0:00 db2loggw (SAMPLE)db2inst1 59048 35124　 0 16:04:50-　0:00 db2pfchrdb2inst1 64010 55852　 0 16:04:50-　0:00 db2agent (SAMPLE)db2inst1 65638 22238　 0 16:04:17-　0:00 db2syscdb2inst1 70018 35124　 0 16:04:50-　0:00 db2pclnrdb2inst1 72120 35124　 0 16:04:51-　0:00 db2event (DB2DETAILDEADLOCK)db2inst1 74198 65638　 0 16:04:17-　0:00 db2syslogdb2inst1 74578 1　 0 16:04:47-　0:00 /home/db2inst1/sqllib/bin/db2bp　50112C14631 5

在連接到SAMPLE數(shù)據(jù)庫后，出現(xiàn)了"db2agent（SAMPLE）"進(jìn)程。這個(gè)進(jìn)程顯示實(shí)際上有一個(gè)到SAMPLE數(shù)據(jù)庫的連接。假如我們運(yùn)行下面的命令：db2 connect resetdb2agent（SAMPLE）將變成db2agent（idle）。這是因?yàn)镹UM_POOLAGENTS設(shè)置為大于0，這意味著代理仍然分配在緩沖池中，雖然它時(shí)空閑的。假如NUM_POOLAGENTS設(shè)置為0，那么在"connect reset"后，就沒有db2agent進(jìn)程運(yùn)行了。

SAMPLE數(shù)據(jù)庫的數(shù)據(jù)庫配置文件有下面的設(shè)置：

Number of asynchronous page cleaners　 (NUM_IOCLEANERS) = 1Number of I/O servers　 (NUM_IOSERVERS) = 3　　注重有三個(gè)db2pfchr進(jìn)程，他們與NUM_IOSERVERS的值相對(duì)應(yīng)，有一個(gè)db2pclnr進(jìn)程與NUM_IOCLEANERS的值相對(duì)應(yīng)。

總結(jié)

還有許多其它的進(jìn)程可能出現(xiàn)或者不出現(xiàn)，這依靠于不同的DB2行為和配置設(shè)定。我們演示了怎樣調(diào)查哪個(gè)進(jìn)程正在運(yùn)行、這些進(jìn)程顯示什么信息、以及它們受到數(shù)據(jù)庫設(shè)置怎樣的影響的示例。現(xiàn)在你能使用這些知識(shí)提高治理DB2數(shù)據(jù)庫的能力。