深入了解IBM DB2的通信與連接過程
本文詳細描述了 DB2® Universal Database™（DB2 UDB）代理的工作原理以及連接集中器的特性，並對 DB2 連接上常見的問題及代理的優化作了詳細的分析。希望通過本文讓用戶能夠了解 DB2 的連接機制和客戶端與服務器端的交互作用，可以解決在實際的商業環境中遇到的性能問題。
簡介
DB2 的代理 (agent) 是位於 DB2 服務器中的服務於應用程序請求的一些進程或線程。當有外部應用程序連接至 DB2 實例提出訪問請求時，DB2 的代理就會被激活去應答這些請求。一般 DB2 的代理被稱為工作代理，工作代理大概有三種類型：空閒代理、活動的協調代理、子代理。
◆空閒代理：指的是沒有任何任務的代理。這種代理不服務於任何遠程連接也不服務於本地連接，處於一種備用或待命狀態。
◆活動的協調代理：指的是處於工作狀態的代理，每一個外部應用程序產生的數據庫活動連接的都有一個活動協調代理來為它服務。
◆子代理：指的是接受協調代理分發出來的工作的下一級代理。在 DB2 V95 以前，只有在多分區環境 (MPP) 或節點內並行環境 (SMP) 下才存在子代理，在 DB2 V95 中所有環境中都可能存在子代理。
在 DB2 服務器中有一個代理池，當實例剛啟動後這裡便有一些代理（其數量取決於實例參數 NUM_INITAGENTS）。在沒有任何數據庫連接時，它們處於待命狀態，就是空閒代理。而當有外部程序連接至數據庫時，這些代理開始得到命令去服務於這些新建的連接，這時它們就變成了活動的協調代理。這些協調代理再將請求逐步細分，分配給下一級代理即子代理去處理。如果當前的代理都已經在工作了，同時又來了新的請求，數據庫管理器會產生一個新的代理去應答。當事務處理完畢而且數據庫連接斷開後，協調代理要麼返回代理池變回空閒代理，要麼就自動消失了（取決於實例參數 NUM_POOLAGENTS）。這就是一個代理的生命周期。
相關的配置參數
通過執行 DB2 get dbm cfg 可以看到以下幾個和代理相關的實例參數：MAXAGENTS，NUM_POOLAGENTS，NUM_INITAGENTS，MAX_COORDAGENTS，MAX_CONNECTIONS，MAXCAGENTS。下面對它們做一下簡要介紹：
◆MAXAGENTS：這個參數為當前實例中全部代理的數量，包括協調代理，空閒代理和子代理之和。不過這個參數在 DB2 V95 中已經不再使用了。
◆NUM_POOLAGENTS：這個參數用來控制代理池中的空閒代理的數量。當活動的代理完成工作返回代理池變成空閒代理時，如果數量超過了這個參數，那麼這個代理就會自動消失了。注意：在連接集中器激活的情況下，代理池中的空閒代理數目在某一時刻可能會超過 NUM_POOLAGENTS 的大小，以應對突發的高密度連接。
◆NUM_INITAGENTS：這個參數就是前面提到的在實例剛剛啟動時便生成的一些空閒代理的數目。這是為了提高性能，因為這些代理可以隨時變成協調代理去應答外部應用請求，而不用臨時再生成新的代理。
◆MAX_COORDAGENTS：這個參數決定了在實例中在同一時刻最大的協調代理的數目 ( 在多分區環境指的是一個節點上的最大協調代理數 )。
◆MAX_CONNECTIONS：這個參數決定了允許連接至一個實例的最大的連接數 ( 在多分區環境指的是一個節點上的最大連接數 )。
◆MAXCAGENT：這個參數決定了實例中的令牌的數量，一個協調代理只有得到了令牌才能去服務於應用程序。當沒有得到令牌時，協調代理只能等候。不過這個參數在 DB2 V95 中也已經取消了。
還有一個連接參數 MAXAPPLS 可以通過 db2 get db cfg for database_name 得到，它是一個數據庫級別的參數，這個參數決定了同時連接至一個數據庫的最大連接數。在一個實例下的所有數據庫的 MAXAPPLS 值之和不能超過實例參數 MAX_CONNECTIONS。
連接集中器
1. 基本原理
從 DB2 V8 開始，DB2 實例中有一個叫做連接集中器的特性，可以用來優化數據庫的連接。缺省情況下，在實例創建的時候，MAX_CONNECTIONS 與 MAX_COORDAGENTS 的值是一致的。這個時候每一個協調代理唯一地服務於一個連接。比如說有 1000 個連接就要有 1000 個協調代理為之服務。這對服務器是一個很大的負擔，因為每一個代理都要消耗一定的資源。而當我們將 MAX_CONNECTIONS 的值設定的比 MAX_COORDAGENTS 大，這時 DB2 的連接集中器就被激活了。它允許多個連接對應於一個代理。
連接集中器的功能與 DB2 CONNECT 中的連接池相似。不過連接集中器比連接池的優點在於它能夠重用外部連接，即多個排隊的應用程序可以重復使用一個存在的連接，而連接池則需要先刪除再重建一個連接去服務於一個新的應用程序。在連接集中器中每個協調代理並不唯一地服務於一個連接，當某個外部連接斷開後，協調代理被分配給其他連接。這樣。同時允許更多的連接連到數據庫，並且減少了每個連接的內存消耗，避免了頻繁的刪除和創建代理所帶來的系統開銷。下面是連接集中器的具體工作原理：
首先將 MAX_CONNECTIONS 的值設定的大於 MAX_COORDAGENTS 去激活連接集中器。在連接集中器中代理被分成邏輯代理和工作代理。邏輯代理與外部應用程序對應，它並不對應與某個特定的引擎分配單元 (EDU)。工作代理和前面定義的一樣，是具體的引擎分配單元。當邏輯代理多於工作代理時連接集中器就被激活了。當有多個連接同時連接到服務器時，連接被一一分配給各個邏輯代理。邏輯代理再去請求工作代理的服務。
比方說，代理池是一個飯店，在飯店裡通常都是顧客多於服務員。剛開始，還沒有顧客 ( 相當於外部應用 ) 的時候。有一些值班的服務員在飯店裡待命（相當於實例啟動時在代理池中創建的空閒代理 NUM_INITAGENTS）。一旦來了應用請求（顧客），調度程序（相當於領班）就去安排服務員開始工作，服務員就開始忙起來去招呼顧客。這時服務員的角色相當於協調代理。她們接待完顧客後便將菜單傳達給廚師和小工 ( 相當於子代理 )。而當顧客越來越多，超過了最初的值班服務員數量。服務器就生成新的代理來服務於這些應用，就好像是從員工宿捨叫來更多的服務員來工作。當在場服務員數達到了一個數目 (MAX_COORDAGENTS)，飯店的所有服務員都在工作了，沒有其他的在編服務員了。這時新來的顧客 ( 外部應用 ) 只能坐在座位上等候了。MAX_CONNECTIONS 在這裡相當於飯店裡的總的就餐座位數，當顧客數目 ( 外部應用 ) 達到了這個數值，後來的顧客只能離去了（相當於連不上數據庫）。
這裡需要注意的是 MAX_CONNECTIONS 並不是指同時連在實例上的活動的連接，因為有些連接即使連在實例上了，也要等候協調代理服務，當前活動的連接數與活動的協調代理數相等。當一個協調代理處理完一個應用程序後，它會被分配給其它等候的應用，相當於服務員去服務於其他等待著的顧客。在飯店中還有一些座位是專門為服務員休息准備的 ( 這個座位數相當於 NUM_POOLAGENTS)。當顧客漸漸散去，越來越少的時候，部分服務員 ( 協調代理 ) 已經無事可做，就返回這些座位（變成空閒代理）。當這些座位也被占滿了，那麼再有服務員 ( 協調代理 ) 返回休息時，就沒有可供休息的座位了 ( 假設服務員不能坐就餐座位 )。這些服務員就只有返回員工宿捨了 ( 相當於代理的刪除 )。圖 1 反映了這一流程。圖中實線箭頭表明當前狀態，虛線箭頭表明將要發生的事件。
圖 1. 代理的工作流程圖
2. DB2 V9.5 新特性
在 DB2 V9.5 中有一個新特性，就是 MAX_CONNECTIONS 和 MAX_COORDAGENTS 都可以被設置成 AUTOMATIC。如果你認為系統可以承受所有的連接，同時又想限制被協調代理消耗的資源，你可以只將 MAX_CONNECTIONS 設定為 AUTOMATIC， MAX_COORDAGENTS 設定為一個數值。這時系統認為可以連到實例的連接數時無限的。如果你對最大連接數和協調代理數都不想做限制的話，你可以將它們都設為 AUTOMATIC。如果這時 MAX_CONNECTIONS 設定為 AUTOMATIC 的數值大於 MAX_COORDAGENTS 設定為 AUTOMATIC 的數值，連接集中器也就被激活了。而後，服務器就以剛才的兩個數值之比作為參照 ( 這裡叫做集中率 ) 按比例根據連接數來相應調整協調代理。示例如下：
db2 update dbm cfg using MAX_CONNECTIONS 300 AUTOMATIC;
db2 update dbm cfg using MAX_COORDAGENTS 100 AUTOMATIC;
這時集中率為 300/100=3，當連接在 1 到 100 時會創建協調代理，大於 100 小於 301 時就不會創建新的協調代理了。再從 301 增加到 400，又會增加 100 個協調代理，大於 400 小於 601 時又停止增加了……即每增加 300 個連接會增加 100 個協調代理。當前的具體數值可以通過 db2 attach to instance_name， db2 get dbm cfg show detail 得到。在這裡允許設為 AUTOMATIC 有下面兩種情況：
◆MAX_CONNECTIONS 為 AUTOMATIC 而 MAX_COORDAGENTS 為一定值。
◆MAX_CONNECTIONS 與 MAX_COORDAGENTS 同時為 AUTOMATIC。
當然連接集中器也有一些局限性：
◆聯邦數據庫不支持連接集中器
◆連接集中器對使用 withhold feature 的應用程序無效
◆全局臨時表在事務完成時必須顯式關閉，否則連接集中器就會被關閉
◆連接兩階段提交事務的連接只能用來連接兩階段提交事務的連接，同理連接一階段提交事務的連接◆也只能用來連接一階段提交事務的連接。
◆不能在線激活連接集中器，也就是說，需要重啟實例才可生效。
如果既不想使用連接集中器，又不想限制數據庫連接的數目，可以運行下面的命令：
db2 update dbm cfg using MAX_COORDAGENTS AUTOMATIC；
db2 update dbm cfg using MAX_CONNECTIONS AUTOMATIC；
代理和連接常見問題分析與優化
1．連接超限問題
在 DB2 V8，V9.1 中所設置的 MAX_CONNECTIONS 或 MAXAGENTS 值比較小時，如果出現了外部連接數過多就會出現錯誤。錯誤如清單 1 所示。
清單 1. db2diag.log 診斷日志
2008-01-15-14.30.13.090289-360 I12983210A1195 LEVEL: Info
PID : 762076 TID : 772 PROC : db2acd
INSTANCE: db2inst1 NODE : 000
APPID : *LOCAL.db2inst1.080115203015
EDUID : 772 EDUNAME: db2acd
FUNCTION: DB2 UDB, DRDA Communication Manager, sqljcReceive, probe:30
MESSAGE : ZRC=0x8136001C=-2127167460=SQLZ_RC_NO_CONNECTION, SQLT_SQLJC
"No connection"
DATA #1 : String, 11 bytes
CCI Error:
DATA #2 : unsigned integer, 8 bytes
...
這時可以通過下面命令來查看當前的連接數：
清單 2. 查看當前的連接數
$ db2 list applications
Auth Id Application Appl. Application Id
DB # of
Name Handle
Name Agents
-------- -------------- ---------- ---------------------------------------------
----------------- -------- -----
DB2INST1 db2taskd 583 *LOCAL.db2inst1.080112150958
SVT_DB 1
DB2INST1 db2stmm 582 *LOCAL.db2inst1.080112150957
SVT_DB 1
DB2INST1 Java 592 *LOCAL.db2inst1.080115201505
SVT_DB 1
DB2INST1 Java 572 *LOCAL.db2inst1.080115201445
SVT_DB 1
DB2INST1 Java 585 *LOCAL.db2inst1.080115201458
SVT_DB 1
DB2INST1 Java 565 *LOCAL.db2inst1.080115201437
SVT_DB 1
DB2INST1 Java 584 *LOCAL.db2inst1.080115201457
SVT_DB 1
DB2INST1 Java 590 *LOCAL.db2inst1.080115201503
SVT_DB 1
DB2INST1 db2bp 591 *LOCAL.db2inst1.080115201502
...
可以查看這時的連接數與 MAX_CONNECTIONS 的值的比較，從而做出調整。這時應當注意，在 v9.1 或 v9.5 環境下，有兩個服務器內部的特殊應用 db2stmm 和 db2taskd 不應算作外部連接。db2stmm 是用來管理內存自動調節特性的代理，db2taskd 是用來分配數據庫後台任務的代理。示例中的 java 代表外部連接來自 Java 應用程序。db2bp 代表來自 CLP(DB2 命令窗口 ) 的一個連接。可以看到這些連接都連到了數據庫 SVT_DB 上。
接下來可以通過 db2pd 命令來查看當前的代理數：
清單 3. 通過 db2pd 命令來查看當前的代理數
$ db2pd –agents –db SVT_DB
Database Partition 0 -- Active -- Up 1 days 01:24:44
Agents:
Current agents: 36
Idle agents: 0
Active coord agents: 28
Active agents total: 28
Pooled coord agents: 8
Pooled agents total: 8
Address AppHandl [nod-index] AgentEDUID Priority Type State
ClientPid Userid ClIEntNm Rowsread Rowswrtn LkTmOt DBName
0x0780000000DABD60 522 [000-00522] 2315 0 Coord Inst-Act
ive 655614 db2inst1 db2bp 375793 9620 NotSet SVT_DB
0x07800000027A4160 523 [000-00523] 6170 0 Coord Inst-Act
ive 655614 db2inst1 db2stmm 0 0 NotSet SVT_DB
0x07800000027A5700 524 [000-00524] 6427 0 Coord Inst-Act
ive 655614 db2inst1 db2taskd 0 0 NotSet SVT_DB
0x0780000000DAD840 525 [000-00525] 5158 0 Coord Inst-Act
ive 655614 db2inst1 db2wlmd 0 0 NotSet SVT_DB
0x07800000027A0080 526 [000-00526] 5415 0 Coord Inst-Act
ive 655614 db2inst1 db2evml_ 0 0 3 SVT_DB
0x07800000028C0080 566 [000-00566] 10810 0 Coord Inst-Act
ive 905284 db2inst1 Java 160282 102 NotSet SVT_DB
0x07800000027AB2C0 567 [000-00567] 7469 0 Coord Inst-Act
...
在這裡看到 Idle agents 值為 0 表明代理池中已經沒有空閒代理了（State 全都是 Inst-Active）。這時可以將 Current agents 的值與 MAXAGENTS 的值的比較，或者 Active agents total 的值與 MAX_COORDAGENTS 的值的比較，從而做出相應調整。
對於這種問題還可以通過分析數據庫管理器的快照來作出調整：
清單 4. 分析數據庫管理器的快照
db2 get snapshot for dbm：
...
Remote Connection Executing in the Database Manager = 58
Local Connection Executing in the Database Manager = 1
...
Agents assigned from pool = 38
Agents created from empty pool = 158
Agents stolen from another application = 1
High water mark for coordinating agents = 60
Max agents overflow = 3
Hash joins after heap threshold exceeded = 0
……
可以看到 Max agents overflow 的值等於 3，說明有 3 次生成代理數超過限制的情況。這時會在 DB2diag.log 中看到前面的錯誤信息。此時必須調節 MAXAGENTS 的值以修復當前錯誤。可以將 MAX_COORDAGENTS 設定為與 High water mark for coordinating agents 相同的值，在單分區環境下可以將 MAXAGENTS 設定與 MAX_COORDAGENTS 一樣，在多分區環境 (MPP) 或節點內並行環境 (SMP) 中，根據節點數來計算出結果 MAXAGENTS =(N+1)* MAX_COORDAGENTS (N 為節點數 )。另一方面在 MAX_COORDAGENTS 不是 AUTOMATIC 的情況下，如果 Remote Connection Executing in the Database Manager 的值與 Local Connection Executing in the Database Manager 的值之和接近 MAX_COORDAGENTS，這時要適當增大 MAX_COORDAGENTS 的值。
一般說來有這樣的原則，當在連接數據庫是出現內存錯誤時，調節如下參數：
◆在單分區並且沒有節點內並行性 (SMP) 的情況下增大 MAXAGENTS 的值。
◆在多分區 (MPP) 或者節點內並行環境 (SMP) 的情況下增大 MAXAGENTS 或 MAX_COORDAGENTS 的值。
◆在連接集中器激活的情況下，增大 MAX_CONNECTIONS 的值。
2. 連接掛起問題
還有一個與連接相關的問題：在首次連接數據庫時，連接時間總要長一些。這是因為數據庫在為首次連接分配內存，主要是緩沖池。連接時間長短取決於操作系統的內存調用情況以及緩沖池的大小。有時用戶常常會為了提高應用性能盲目的擴大緩沖池，造成緩沖池設置得太大，甚至超過了數據庫共享內存，使得實例無法為數據庫分配足夠的內存，在連接數據庫時就會出現掛起現象。而這時想將緩沖池設小也沒辦法了，因為數據庫連不上，無法設置緩沖池。這也是一個常見的問題。遇到這種問題時，有些用戶甚至被迫重建數據庫。其實這個問題可以通過設置 DB2 注冊參數 DB2_OVERRIDE_BPF 來設置緩沖池的大小，從而能夠再次連接數據庫。在缺省情況下 (v9.1，v9.5) 緩沖池的大小被設置成 -2（通過 select npages from syscat.BUFFERPOOLS 得到），這說明緩沖池時自動增長的，這種情況下最好不要修改緩沖池的大小，可以讓 DB2 自動去調節。
3. 常見通信錯誤
通常在連接數據庫時還會遇到的一些與網絡通信相關的錯誤，這些錯誤號如：SQL30080，SQL30081 等等。可以用以下一些方法去嘗試解決：
◆執行命令 db2set –all 來檢查一下是否有 DB2COMM=TCPIP 一項，如果沒有則應該添加上。
◆執行命令 db2 get dbm cfg | grep SVCENAME 來檢查 SVCENAME 設定的服務是否在 /etc/services(UNIX) 中定義了 (Windows 是在 %windir%system32driversetc services)。當然如果 SVCENAME 是一個端口號，則不用在 services 中定義。（端口號應小於 65536）
◆執行命令 netstat –a 檢查輸出中是否有 services 中定義的端口或服務在監聽。如果沒有，則可能需要重啟網絡或機器。
◆這種問題也可能是防火牆導致的，在 Linux 上可以通過編輯 /etc/sysconfig/iptables 文件來繞過防火牆 ( 需要 root 權限 )。
◆在 WINDOWS 有時還會遇到“No buffer space available(maximum connections reached?)”的錯誤消息，這種錯誤和 DB2 無關，需要增大 Windows 的注冊表參數值：
◆HKEY_LOCAL_MacHINESYSTEMCurrentControlSetControlSession ManagerMemory ManagementSystemPages
如果遇到其他特殊的問題可以通過命令 DB2 ? sqlxxxxx 來根據得到的提示去分析具體問題。
4. 性能優化
調節 NUM_POOLAGENTS:
對於決策支持系統，由於連接數較少，NUM_POOLAGENTS 可以設為一個較小的值從而避免過多的空閒代理而浪費資源。而對於在線事務處理系統，由於連接數較多，可以設為一個較大的值從而減少頻繁創建和刪除代理所產生的系統消耗。具體數值可以通過分析數據庫管理器快照來進行調節 :
清單 5. 通過分析數據庫管理器快照來調節 NUM_POOLAGENTS
db2 get snapshot for dbm
...
Agents assigned from pool = 38
Agents created from empty pool = 158
Agents stolen from another application = 1
...
當 Agents created from empty pool / Agents Assigned From Pool 的比值較小時，說明代理的重用率比較高。當比值比較大時，說明這時代理的創建、刪除比較頻繁，此時需要增大 NUM_POOLAGENTS 來減少系統頻繁創建、刪除代理時的資源消耗。當 Agents stolen from another application 的值較大時也應當增大 NUM_POOLAGENTS 的值。當然如果 NUM_POOLAGENTS 設得太大，可能會產生很多不必要的空閒代理長時間滯留在代理池中，造成資源的浪費。在 V8，V9.1 中 NUM_POOLAGENTS 的缺省值為 MAXAGENTS 的值的一半，而在 V9.5 中 NUM_POOLAGENTS 的缺省值被設為 AUTOMATIC( 初始值為 100)，這樣數據庫管理器可以自動管理代理池中空閒代理的數目。
調節 NUM_INITAGENTS：
NUM_INITAGENTS 的值最好和 NUM_POOLAGENTS 值一致。這樣可以減少處理事務時生成代理的時間，而將這部分等待時間轉移到啟動實例時，這對用戶來說是最理想的。
調節 MAX_CONNECTIONS 與 MAX_COORDAGENTS：
激活連接集中器，即設定 MAX_CONNECTIONS 大於 MAX_COORDAGENTS，這樣可以節省 DB2 代理的數目，減少資源消耗，擴大連接數。在 V9.5 中最好將 MAX_CONNECTIONS 與 MAX_COORDAGENTS 都設為 AUTOMATIC，這樣可以讓 DB2 自動根據連接數來調節代理數。
DB2 V8，V9.1，V9.5 代理的差異性
DB2 在從 V8 到 V95 中代理特性有很多的改變，表 1 中列舉了一些典型的特性上的差異供讀者參考。
表 1：DB2 不同版本之間代理的差異性
結束語
通過以上對 DB2 代理和連接特性的介紹，希望讀者能夠對 DB2 的通信與連接過程有一個清晰的了解。也希望讀者能夠了解 DB2 V9.5 中的代理新特性，並能夠利用這些新特性更好地優化數據庫。
