簡介
??? DB2 的代理 (agent) 是位于 DB2 服務(wù)器中的服務(wù)于應(yīng)用程序" title="應(yīng)用程序">應(yīng)用程序請求的一些進(jìn)程或線程。當(dāng)有外部應(yīng)用程序連接至 DB2 實(shí)例提出訪問請求時，DB2 的代理就會被激活去應(yīng)答這些請求。一般 DB2 的代理被稱為工作代理，工作代理大概有三種類型：空閑代理、活動的協(xié)調(diào)代理、子代理。
??? ◆空閑代理：指的是沒有任何任務(wù)的代理。這種代理不服務(wù)于任何遠(yuǎn)程連接也不服務(wù)于本地連接，處于一種備用或待命狀態(tài)。
??? ◆活動的協(xié)調(diào)代理：指的是處于工作狀態(tài)的代理，每一個外部應(yīng)用程序產(chǎn)生的數(shù)據(jù)庫活動連接的都有一個活動協(xié)調(diào)代理來為它服務(wù)。
??? ◆子代理：指的是接受協(xié)調(diào)代理分發(fā)出來的工作的下一級代理。在 DB2 V95 以前，只有在多分區(qū)環(huán)境 (MPP) 或節(jié)點(diǎn)內(nèi)并行環(huán)境 (SMP) 下才存在子代理，在 DB2 V95 中所有環(huán)境中都可能存在子代理。
??? 在 DB2 服務(wù)器中有一個代理池，當(dāng)實(shí)例剛啟動后這里便有一些代理（其數(shù)量取決于實(shí)例參數(shù) NUM_INITAGENTS）。在沒有任何數(shù)據(jù)庫連接時，它們處于待命狀態(tài)，就是空閑代理。而當(dāng)有外部程序連接至數(shù)據(jù)庫時，這些代理開始得到命令去服務(wù)于這些新建的連接，這時它們就變成了活動的協(xié)調(diào)代理。這些協(xié)調(diào)代理再將請求逐步細(xì)分，分配給下一級代理即子代理去處理。如果當(dāng)前的代理都已經(jīng)在工作了，同時又來了新的請求，數(shù)據(jù)庫管理器" title="管理器">管理器會產(chǎn)生一個新的代理去應(yīng)答。當(dāng)事務(wù)處理完畢而且數(shù)據(jù)庫? 連接斷開后，協(xié)調(diào)代理要么返回代理池變回空閑代理，要么就自動消失了（取決于實(shí)例參數(shù) NUM_POOLAGENTS）。這就是一個代理的生命周期。
相關(guān)的配置參數(shù)
??? 通過執(zhí)行 DB2 get dbm cfg 可以看到以下幾個和代理相關(guān)的實(shí)例參數(shù)：MAXAGENTS，NUM_POOLAGENTS，NUM_INITAGENTS，MAX_COORDAGENTS，MAX_CONNECTIONS，MAXCAGENTS。下面對它們做一下簡要介紹：
??? ◆MAXAGENTS：這個參數(shù)為當(dāng)前實(shí)例中全部代理的數(shù)量，包括協(xié)調(diào)代理，空閑代理和子代理之和。不過這個參數(shù)在 DB2 V95 中已經(jīng)不再使用了。
??? ◆NUM_POOLAGENTS：這個參數(shù)用來控制代理池中的空閑代理的數(shù)量。當(dāng)活動的代理完成工作返回代理池變成空閑代理時，如果數(shù)量超過了這個參數(shù)，那么這個代理就會自動消失了。注意：在連接集中器激活的情況下，代理池中的空閑代理數(shù)目在某一時刻可能會超過 NUM_POOLAGENTS 的大小，以應(yīng)對突發(fā)的高密度連接。
??? ◆NUM_INITAGENTS：這個參數(shù)就是前面提到的在實(shí)例剛剛啟動時便生成的一些空閑代理的數(shù)目。這是為了提高性能，因?yàn)檫@些代理可以隨時變成協(xié)調(diào)代理去應(yīng)答外部應(yīng)用請求，而不用臨時再生成新的代理。
??? ◆MAX_COORDAGENTS：這個參數(shù)決定了在實(shí)例中在同一時刻最大" title="最大">最大的協(xié)調(diào)代理的數(shù)目 ( 在多分區(qū)環(huán)境指的是一個節(jié)點(diǎn)上的最大協(xié)調(diào)代理數(shù) )。
??? ◆MAX_CONNECTIONS：這個參數(shù)決定了允許連接至一個實(shí)例的最大的連接數(shù)" title="連接數(shù)">連接數(shù) ( 在多分區(qū)環(huán)境指的是一個節(jié)點(diǎn)上的最大連接數(shù) )。
??? ◆MAXCAGENT：這個參數(shù)決定了實(shí)例中的令牌的數(shù)量，一個協(xié)調(diào)代理只有得到了令牌才能去服務(wù)于應(yīng)用程序。當(dāng)沒有得到令牌時，協(xié)調(diào)代理只能等候。不過這個參數(shù)在 DB2 V95 中也已經(jīng)取消了。
??? 還有一個連接參數(shù) MAXAPPLS 可以通過 db2 get db cfg for database_name 得到，它是一個數(shù)據(jù)庫級別的參數(shù)，這個參數(shù)決定了同時連接至一個數(shù)據(jù)庫的最大連接數(shù)。在一個實(shí)例下的所有數(shù)據(jù)庫的 MAXAPPLS 值之和不能超過實(shí)例參數(shù)MAX_CONNECTIONS。
連接集中器
1. 基本原理
??? 從 DB2 V8 開始，DB2 實(shí)例中有一個叫做連接集中器的特性，可以用來優(yōu)化數(shù)據(jù)庫的連接。缺省情況下，在實(shí)例創(chuàng)建的時候，MAX_CONNECTIONS 與 MAX_COORDAGENTS 的值是一致的。這個時候每一個協(xié)調(diào)代理唯一地服務(wù)于一個連接。比如說有 1000 個連接就要有 1000 個協(xié)調(diào)代理為之服務(wù)。這對服務(wù)器是一個很大的負(fù)擔(dān)，因?yàn)槊恳粋€代理都要消耗一定的資源。而當(dāng)我們將 MAX_CONNECTIONS 的值設(shè)定的比 MAX_COORDAGENTS 大，這時 DB2 的連接集中器就被激活了。它允許多個連接對應(yīng)于一個代理。
??? 連接集中器的功能與 DB2 CONNECT 中的連接池相似。不過連接集中器比連接池的優(yōu)點(diǎn)在于它能夠重用外部連接，即多個排隊(duì)的應(yīng)用程序可以重復(fù)使用一個存在的連接，而連接池則需要先刪除再重建一個連接去服務(wù)于一個新的應(yīng)用程序。在連接集中器中每個協(xié)調(diào)代理并不唯一地服務(wù)于一個連接，當(dāng)某個外部連接斷開后，協(xié)調(diào)代理被分配給其他連接。這樣。同時允許更多的連接連到數(shù)據(jù)庫，并且減少了每個連接的內(nèi)存消耗，避免了頻繁的刪除和創(chuàng)建代理所帶來的系統(tǒng)開銷。下面是連接集中器的具體工作原理：
??? 首先將 MAX_CONNECTIONS 的值設(shè)定的大于 MAX_COORDAGENTS 去激活連接集中器。在連接集中器中代理被分成邏輯代理和工作代理。邏輯代理與外部應(yīng)用程序?qū)?yīng)，它并不對應(yīng)與某個特定的引擎分配單元 (EDU)。工作代理和前面定義的一樣，是具體的引擎分配單元。當(dāng)邏輯代理多于工作代理時連接集中器就被激活了。當(dāng)有多個連接同時連接到服務(wù)器時，連接被一一分配給各個邏輯代理。邏輯代理再去請求工作代理的服務(wù)。
??? 比方說，代理池是一個飯店，在飯店里通常都是顧客多于服務(wù)員。剛開始，還沒有顧客 ( 相當(dāng)于外部應(yīng)用 ) 的時候。有一些值班的服務(wù)員在飯店里待命（相當(dāng)于實(shí)例啟動時在代理池中創(chuàng)建的空閑代理 NUM_INITAGENTS）。一旦來了應(yīng)用請求（顧客），調(diào)度程序（相當(dāng)于領(lǐng)班）就去安排服務(wù)員開始工作，服務(wù)員就開始忙起來去招呼顧客。這時服務(wù)員的角色相當(dāng)于協(xié)調(diào)代理。她們接待完顧客后便將菜單傳達(dá)給廚師和小工 ( 相當(dāng)于子代理 )。而當(dāng)顧客越來越多，超過了最初的值班服務(wù)員數(shù)量。服務(wù)器就生成新的代理來服務(wù)于這些應(yīng)用，就好像是從員工宿舍叫來更多的服務(wù)員來工作。當(dāng)在場服務(wù)員數(shù)達(dá)到了一個數(shù)目 (MAX_COORDAGENTS)，飯店的所有服務(wù)員都在工作了，沒有其他的在編服務(wù)員了。這時新來的顧客 ( 外部應(yīng)用 ) 只能坐在座位上等候了。MAX_CONNECTIONS 在這里相當(dāng)于飯店里的總的就餐座位數(shù)，當(dāng)顧客數(shù)目 ( 外部應(yīng)用 ) 達(dá)到了這個數(shù)值，后來的顧客只能離去了（相當(dāng)于連不上數(shù)據(jù)庫）。
??? 這里需要注意的是 MAX_CONNECTIONS 并不是指同時連在實(shí)例上的活動的連接，因?yàn)橛行┻B接即使連在實(shí)例上了，也要等候協(xié)調(diào)代理服務(wù)，當(dāng)前活動的連接數(shù)與活動的協(xié)調(diào)代理數(shù)相等。當(dāng)一個協(xié)調(diào)代理處理完一個應(yīng)用程序后，它會被分配給其它等候的應(yīng)用，相當(dāng)于服務(wù)員去服務(wù)于其他等待著的顧客。在飯店中還有一些座位是專門為服務(wù)員休息準(zhǔn)備的 ( 這個座位數(shù)相當(dāng)于 NUM_POOLAGENTS)。當(dāng)顧客漸漸散去，越來越少的時候，部分服務(wù)員 ( 協(xié)調(diào)代理 ) 已經(jīng)無事可做，就返回這些座位（變成空閑代理）。當(dāng)這些座位也被占滿了，那么再有服務(wù)員 ( 協(xié)調(diào)代理 ) 返回休息時，就沒有可供休息的座位了 ( 假設(shè)服務(wù)員不能坐就餐座位 )。這些服務(wù)員就只有返回員工宿舍了 ( 相當(dāng)于代理的刪除 )。圖 1 反映了這一流程。圖中實(shí)線箭頭表明當(dāng)前狀態(tài)，虛線箭頭表明將要發(fā)生的事件。
??????????? 
????????????????????????????????????? 圖 1. 代理的工作流程圖
2. DB2 V9.5 新特性
??? 在 DB2 V9.5 中有一個新特性，就是 MAX_CONNECTIONS 和 MAX_COORDAGENTS 都可以被設(shè)置成 AUTOMATIC。如果你認(rèn)為系統(tǒng)可以承受所有的連接，同時又想限制被協(xié)調(diào)代理消耗的資源，你可以只將 MAX_CONNECTIONS 設(shè)定為 AUTOMATIC， MAX_COORDAGENTS 設(shè)定為一個數(shù)值。這時系統(tǒng)認(rèn)為可以連到實(shí)例的連接數(shù)時無限的。如果你對最大連接數(shù)和協(xié)調(diào)代理數(shù)都不想做限制的話，你可以將它們都設(shè)為 AUTOMATIC。如果這時 MAX_CONNECTIONS 設(shè)定為 AUTOMATIC 的數(shù)值大于 MAX_COORDAGENTS 設(shè)定為 AUTOMATIC 的數(shù)值，連接集中器也就被激活了。而后，服務(wù)器就以剛才的兩個數(shù)值之比作為參照 ( 這里叫做集中率 ) 按比例根據(jù)連接數(shù)來相應(yīng)調(diào)整協(xié)調(diào)代理。示例如下：
??? db2 update dbm cfg using MAX_CONNECTIONS 300 AUTOMATIC;
??? db2 update dbm cfg using MAX_COORDAGENTS 100 AUTOMATIC;
??? 這時集中率為 300/100=3，當(dāng)連接在 1 到 100 時會創(chuàng)建協(xié)調(diào)代理，大于 100 小于 301 時就不會創(chuàng)建新的協(xié)調(diào)代理了。再從 301 增加到 400，又會增加 100 個協(xié)調(diào)代理，大于 400 小于 601 時又停止增加了……即每增加 300 個連接會增加 100 個協(xié)調(diào)代理。當(dāng)前的具體數(shù)值可以通過 db2 attach to instance_name， db2 get dbm cfg show detail 得到。在這里允許設(shè)為 AUTOMATIC 有下面兩種情況：
??? ◆MAX_CONNECTIONS 為 AUTOMATIC 而 MAX_COORDAGENTS 為一定值。
??? ◆MAX_CONNECTIONS 與 MAX_COORDAGENTS 同時為 AUTOMATIC。
當(dāng)然連接集中器也有一些局限性：
??? ◆聯(lián)邦數(shù)據(jù)庫不支持連接集中器
??? ◆連接集中器對使用 withhold feature 的應(yīng)用程序無效
??? ◆全局臨時表在事務(wù)完成時必須顯式關(guān)閉，否則連接集中器就會被關(guān)閉
??? ◆連接兩階段提交事務(wù)的連接只能用來連接兩階段提交事務(wù)的連接，同理連接一階段提交事務(wù)的連接◆也只能用來連接一階段提交事務(wù)的連接。
??? ◆不能在線激活連接集中器，也就是說，需要重啟實(shí)例才可生效。
??? 如果既不想使用連接集中器，又不想限制數(shù)據(jù)庫連接的數(shù)目，可以運(yùn)行下面的命令：
??? db2 update dbm cfg using MAX_COORDAGENTS AUTOMATIC；
??? db2 update dbm cfg using MAX_CONNECTIONS AUTOMATIC；
??? 代理和連接常見問題分析與優(yōu)化
1．連接超限問題
??? 在 DB2 V8，V9.1 中所設(shè)置的 MAX_CONNECTIONS 或 MAXAGENTS 值比較小時，如果出現(xiàn)了外部連接數(shù)過多就會出現(xiàn)錯誤。錯誤如清單 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
??? ...
??? 這時可以通過下面命令來查看當(dāng)前的連接數(shù)：
清單 2. 查看當(dāng)前的連接數(shù)
＄ 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
...
??? 可以查看這時的連接數(shù)與 MAX_CONNECTIONS 的值的比較，從而做出調(diào)整。這時應(yīng)當(dāng)注意，在 v9.1 或 v9.5 環(huán)境下，有兩個服務(wù)器內(nèi)部的特殊應(yīng)用 db2stmm 和 db2taskd 不應(yīng)算作外部連接。db2stmm 是用來管理內(nèi)存自動調(diào)節(jié)特性的代理，db2taskd 是用來分配數(shù)據(jù)庫后臺任務(wù)的代理。示例中的 java 代表外部連接來自 JAVA 應(yīng)用程序。db2bp 代表來自 CLP(DB2 命令窗口 ) 的一個連接。可以看到這些連接都連到了數(shù)據(jù)庫 SVT_DB 上。
接下來可以通過 db2pd 命令來查看當(dāng)前的代理數(shù)：
清單 3. 通過 db2pd 命令來查看當(dāng)前的代理數(shù)
＄ 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 表明代理池中已經(jīng)沒有空閑代理了（State 全都是 Inst-Active）。這時可以將 Current agents 的值與 MAXAGENTS 的值的比較，或者 Active agents total 的值與 MAX_COORDAGENTS 的值的比較，從而做出相應(yīng)調(diào)整。
??? 對于這種問題還可以通過分析數(shù)據(jù)庫管理器的快照來作出調(diào)整：
清單 4. 分析數(shù)據(jù)庫管理器的快照
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 次生成代理數(shù)超過限制的情況。這時會在 DB2diag.log 中看到前面的錯誤信息。此時必須調(diào)節(jié) MAXAGENTS 的值以修復(fù)當(dāng)前錯誤。可以將 MAX_COORDAGENTS 設(shè)定為與 High water mark for coordinating agents 相同的值，在單分區(qū)環(huán)境下可以將 MAXAGENTS 設(shè)定與 MAX_COORDAGENTS 一樣，在多分區(qū)環(huán)境 (MPP) 或節(jié)點(diǎn)內(nèi)并行環(huán)境 (SMP) 中，根據(jù)節(jié)點(diǎn)數(shù)來計(jì)算出結(jié)果 MAXAGENTS =(N+1)* MAX_COORDAGENTS (N 為節(jié)點(diǎn)數(shù) )。另一方面在 MAX_COORDAGENTS 不是 AUTOMATIC 的情況下，如果 Remote Connection Executing in the Database Manager 的值與 Local Connection Executing in the Database Manager 的值之和接近 MAX_COORDAGENTS，這時要適當(dāng)增大 MAX_COORDAGENTS 的值。
??? 一般說來有這樣的原則，當(dāng)在連接數(shù)據(jù)庫是出現(xiàn)內(nèi)存錯誤時，調(diào)節(jié)如下參數(shù)：
??? ◆在單分區(qū)并且沒有節(jié)點(diǎn)內(nèi)并行性 (SMP) 的情況下增大 MAXAGENTS 的值。
??? ◆在多分區(qū) (MPP) 或者節(jié)點(diǎn)內(nèi)并行環(huán)境 (SMP) 的情況下增大 MAXAGENTS 或 MAX_COORDAGENTS 的值。
??? ◆在連接集中器激活的情況下，增大 MAX_CONNECTIONS 的值。
2. 連接掛起問題
??? 還有一個與連接相關(guān)的問題：在首次連接數(shù)據(jù)庫時，連接時間總要長一些。這是因?yàn)閿?shù)據(jù)庫在為首次連接分配內(nèi)存，主要是緩沖池。連接時間長短取決于操作系統(tǒng)的內(nèi)存調(diào)用情況以及緩沖池的大小。有時用戶常常會為了提高應(yīng)用性能盲目的擴(kuò)大緩沖池，造成緩沖池設(shè)置得太大，甚至超過了數(shù)據(jù)庫共享內(nèi)存，使得實(shí)例無法為數(shù)據(jù)庫分配足夠的內(nèi)存，在連接數(shù)據(jù)庫時就會出現(xiàn)掛起現(xiàn)象。而這時想將緩沖池設(shè)小也沒辦法了，因?yàn)閿?shù)據(jù)庫連不上，無法設(shè)置緩沖池。這也是一個常見的問題。遇到這種問題時，有些用戶甚至被迫重建數(shù)據(jù)庫。其實(shí)這個問題可以通過設(shè)置 DB2 注冊參數(shù) DB2_OVERRIDE_BPF 來設(shè)置緩沖池的大小，從而能夠再次連接數(shù)據(jù)庫。在缺省情況下 (v9.1，v9.5) 緩沖池的大小被設(shè)置成 -2（通過 select npages from syscat.BUFFERPOOLS 得到），這說明緩沖池時自動增長的，這種情況下最好不要修改緩沖池的大小，可以讓 DB2 自動去調(diào)節(jié)。
3. 常見通信錯誤
??? 通常在連接數(shù)據(jù)庫時還會遇到的一些與網(wǎng)絡(luò)通信相關(guān)的錯誤，這些錯誤號如：SQL30080，SQL30081 等等。可以用以下一些方法去嘗試解決：
??? ◆執(zhí)行命令 db2set –all 來檢查一下是否有 DB2COMM=TCPIP 一項(xiàng)，如果沒有則應(yīng)該添加上。
??? ◆執(zhí)行命令 db2 get dbm cfg | grep SVCENAME 來檢查 SVCENAME 設(shè)定的服務(wù)是否在 /etc/services(UNIX) 中定義了 (WINDOWS 是在 %windir%system32driversetc services)。當(dāng)然如果 SVCENAME 是一個端口號，則不用在 services 中定義。（端口號應(yīng)小于 65536）
??? ◆執(zhí)行命令 netstat –a 檢查輸出中是否有 services 中定義的端口或服務(wù)在監(jiān)聽。如果沒有，則可能需要重啟網(wǎng)絡(luò)或機(jī)器。
??? ◆這種問題也可能是防火墻導(dǎo)致的，在 Linux 上可以通過編輯 /etc/sysconfig/iptables 文件來繞過防火墻 ( 需要 root 權(quán)限 )。
??? ◆在 WINDOWS 有時還會遇到“No buffer space available(maximum connections reached?)”的錯誤消息，這種錯誤和 DB2 無關(guān)，需要增大 WINDOWS 的注冊表參數(shù)值：
??? ◆HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory ManagementSystemPages
??? 如果遇到其他特殊的問題可以通過命令 DB2 ? sqlxxxxx 來根據(jù)得到的提示去分析具體問題。
4. 性能優(yōu)化
調(diào)節(jié) NUM_POOLAGENTS:
??? 對于決策支持系統(tǒng)，由于連接數(shù)較少，NUM_POOLAGENTS 可以設(shè)為一個較小的值從而避免過多的空閑代理而浪費(fèi)資源。而對于在線事務(wù)處理系統(tǒng)，由于連接數(shù)較多，可以設(shè)為一個較大的值從而減少頻繁創(chuàng)建和刪除代理所產(chǎn)生的系統(tǒng)消耗。具體數(shù)值可以通過分析數(shù)據(jù)庫管理器快照來進(jìn)行調(diào)節(jié) :
清單 5. 通過分析數(shù)據(jù)庫管理器快照來調(diào)節(jié) NUM_POOLAGENTS
db2 get snapshot for dbm
...
Agents assigned from pool = 38
Agents created from empty pool = 158
Agents stolen from another application = 1
...
??? 當(dāng) Agents created from empty pool / Agents Assigned From Pool 的比值較小時，說明代理的重用率比較高。當(dāng)比值比較大時，說明這時代理的創(chuàng)建、刪除比較頻繁，此時需要增大 NUM_POOLAGENTS 來減少系統(tǒng)頻繁創(chuàng)建、刪除代理時的資源消耗。當(dāng) Agents stolen from another application 的值較大時也應(yīng)當(dāng)增大 NUM_POOLAGENTS 的值。當(dāng)然如果 NUM_POOLAGENTS 設(shè)得太大，可能會產(chǎn)生很多不必要的空閑代理長時間滯留在代理池中，造成資源的浪費(fèi)。在 V8，V9.1 中 NUM_POOLAGENTS 的缺省值為 MAXAGENTS 的值的一半，而在 V9.5 中 NUM_POOLAGENTS 的缺省值被設(shè)為 AUTOMATIC( 初始值為 100)，這樣數(shù)據(jù)庫管理器可以自動管理代理池中空閑代理的數(shù)目。
調(diào)節(jié) NUM_INITAGENTS：
??? NUM_INITAGENTS 的值最好和 NUM_POOLAGENTS 值一致。這樣可以減少處理事務(wù)時生成代理的時間，而將這部分等待時間轉(zhuǎn)移到啟動實(shí)例時，這對用戶來說是最理想的。
調(diào)節(jié) MAX_CONNECTIONS 與 MAX_COORDAGENTS：
??? 激活連接集中器，即設(shè)定 MAX_CONNECTIONS 大于 MAX_COORDAGENTS，這樣可以節(jié)省 DB2 代理的數(shù)目，減少資源消耗，擴(kuò)大連接數(shù)。在 V9.5 中最好將 MAX_CONNECTIONS 與 MAX_COORDAGENTS 都設(shè)為 AUTOMATIC，這樣可以讓 DB2 自動根據(jù)連接數(shù)來調(diào)節(jié)代理數(shù)。
DB2 V8，V9.1，V9.5 代理的差異性
??? DB2 在從 V8 到 V95 中代理特性有很多的改變，表 1 中列舉了一些典型的特性上的差異供讀者參考。
表 1：DB2 不同版本之間代理的差異性
?????????
結(jié)束語
??? 通過以上對 DB2 代理和連接特性的介紹，希望讀者能夠?qū)?DB2 的通信與連接過程有一個清晰的了解。也希望讀者能夠了解 DB2 V9.5 中的代理新特性，并能夠利用這些新特性更好地優(yōu)化數(shù)據(jù)庫。