深入了解DB2 Universal Database進程(1)

2024-09-06 23:58:08

字體：大中小

來源：轉載

供稿：網友

介紹

　　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一起工作，它成為應用程序的協調程序代理并把連接傳遞到這個代理。在這以后，協調程序代理聯系遠程客戶端應用程序并且連接到數據庫了。

　　本文的后面一部分將講解其它類型的代理（例如并行回復代理，db2agnsc）。下面是顯示db2進程模型的兩個圖表。