agents详解.docx
《agents详解.docx》由会员分享，可在线阅读，更多相关《agents详解.docx（12页珍藏版）》请在冰豆网上搜索。
agents详解
带你深入了解IBMDB2的通信与连接过程
发布时间：
2008.08.0408:
44 来源：
赛迪网 作者：
Alizze
【赛迪网－IT技术报道】本文详细描述了DB2®UniversalDatabase™（DB2UDB）代理的工作原理以及连接集中器的特性，并对DB2连接上常见的问题及代理的优化作了详细的分析。
希望通过本文让用户能够了解DB2的连接机制和客户端与服务器端的交互作用，可以解决在实际的商业环境中遇到的性能问题。
简介
DB2的代理（agent）是位于DB2服务器中的服务于应用程序请求的一些进程或线程。
当有外部应用程序连接至DB2实例提出访问请求时，DB2的代理就会被激活去应答这些请求。
一般DB2的代理被称为工作代理，工作代理大概有三种类型：
空闲代理、活动的协调代理、子代理。
◆空闲代理：
指的是没有任何任务的代理。
这种代理不服务于任何远程连接也不服务于本地连接，处于一种备用或待命状态。
◆活动的协调代理：
指的是处于工作状态的代理，每一个外部应用程序产生的数据库活动连接的都有一个活动协调代理来为它服务。
◆子代理：
指的是接受协调代理分发出来的工作的下一级代理。
在DB2V95以前，只有在多分区环境（MPP）或节点内并行环境（SMP）下才存在子代理，在DB2V95中所有环境中都可能存在子代理。
在DB2服务器中有一个代理池，当实例刚启动后这里便有一些代理（其数量取决于实例参数NUM_INITAGENTS）。
在没有任何数据库连接时，它们处于待命状态，就是空闲代理。
而当有外部程序连接至数据库时，这些代理开始得到命令去服务于这些新建的连接，这时它们就变成了活动的协调代理。
这些协调代理再将请求逐步细分，分配给下一级代理即子代理去处理。
如果当前的代理都已经在工作了，同时又来了新的请求，数据库管理器会产生一个新的代理去应答。
当事务处理完毕而且数据库连接断开后，协调代理要么返回代理池变回空闲代理，要么就自动消失了（取决于实例参数NUM_POOLAGENTS）。
这就是一个代理的生命周期。
相关的配置参数
通过执行DB2getdbmcfg可以看到以下几个和代理相关的实例参数：
MAXAGENTS，NUM_POOLAGENTS，NUM_INITAGENTS，MAX_COORDAGENTS，MAX_CONNECTIONS，MAXCAGENTS。
下面对它们做一下简要介绍：
◆MAXAGENTS：
这个参数为当前实例中全部代理的数量，包括协调代理，空闲代理和子代理之和。
不过这个参数在DB2V95中已经不再使用了。
◆NUM_POOLAGENTS：
这个参数用来控制代理池中的空闲代理的数量。
当活动的代理完成工作返回代理池变成空闲代理时，如果数量超过了这个参数，那么这个代理就会自动消失了。
注意：
在连接集中器激活的情况下，代理池中的空闲代理数目在某一时刻可能会超过NUM_POOLAGENTS的大小，以应对突发的高密度连接。
◆NUM_INITAGENTS：
这个参数就是前面提到的在实例刚刚启动时便生成的一些空闲代理的数目。
这是为了提高性能，因为这些代理可以随时变成协调代理去应答外部应用请求，而不用临时再生成新的代理。
◆MAX_COORDAGENTS：
这个参数决定了在实例中在同一时刻最大的协调代理的数目（在多分区环境指的是一个节点上的最大协调代理数）。
◆MAX_CONNECTIONS：
这个参数决定了允许连接至一个实例的最大的连接数（在多分区环境指的是一个节点上的最大连接数）。
◆MAXCAGENT：
这个参数决定了实例中的令牌的数量，一个协调代理只有得到了令牌才能去服务于应用程序。
当没有得到令牌时，协调代理只能等候。
不过这个参数在DB2V95中也已经取消了。
还有一个连接参数MAXAPPLS可以通过db2getdbcfgfordatabase_name得到，它是一个数据库级别的参数，这个参数决定了同时连接至一个数据库的最大连接数。
在一个实例下的所有数据库的MAXAPPLS值之和不能超过实例参数MAX_CONNECTIONS。
连接集中器
1.基本原理
从DB2V8开始，DB2实例中有一个叫做连接集中器的特性，可以用来优化数据库的连接。
缺省情况下，在实例创建的时候，MAX_CONNECTIONS与MAX_COORDAGENTS的值是一致的。
这个时候每一个协调代理唯一地服务于一个连接。
比如说有1000个连接就要有1000个协调代理为之服务。
这对服务器是一个很大的负担，因为每一个代理都要消耗一定的资源。
而当我们将MAX_CONNECTIONS的值设定的比MAX_COORDAGENTS大，这时DB2的连接集中器就被激活了。
它允许多个连接对应于一个代理。
连接集中器的功能与DB2CONNECT中的连接池相似。
不过连接集中器比连接池的优点在于它能够重用外部连接，即多个排队的应用程序可以重复使用一个存在的连接，而连接池则需要先删除再重建一个连接去服务于一个新的应用程序。
在连接集中器中每个协调代理并不唯一地服务于一个连接，当某个外部连接断开后，协调代理被分配给其他连接。
这样。
同时允许更多的连接连到数据库，并且减少了每个连接的内存消耗，避免了频繁的删除和创建代理所带来的系统开销。
下面是连接集中器的具体工作原理：
首先将MAX_CONNECTIONS的值设定的大于MAX_COORDAGENTS去激活连接集中器。
在连接集中器中代理被分成逻辑代理和工作代理。
逻辑代理与外部应用程序对应，它并不对应与某个特定的引擎分配单元（EDU）。
工作代理和前面定义的一样，是具体的引擎分配单元。
当逻辑代理多于工作代理时连接集中器就被激活了。
当有多个连接同时连接到服务器时，连接被一一分配给各个逻辑代理。
逻辑代理再去请求工作代理的服务。
比方说，代理池是一个饭店，在饭店里通常都是顾客多于服务员。
刚开始，还没有顾客（相当于外部应用）的时候。
有一些值班的服务员在饭店里待命（相当于实例启动时在代理池中创建的空闲代理NUM_INITAGENTS）。
一旦来了应用请求（顾客），调度程序（相当于领班）就去安排服务员开始工作，服务员就开始忙起来去招呼顾客。
这时服务员的角色相当于协调代理。
她们接待完顾客后便将菜单传达给厨师和小工（相当于子代理）。
而当顾客越来越多，超过了最初的值班服务员数量。
服务器就生成新的代理来服务于这些应用，就好像是从员工宿舍叫来更多的服务员来工作。
当在场服务员数达到了一个数目（MAX_COORDAGENTS），饭店的所有服务员都在工作了，没有其他的在编服务员了。
这时新来的顾客（外部应用）只能坐在座位上等候了。
MAX_CONNECTIONS在这里相当于饭店里的总的就餐座位数，当顾客数目（外部应用）达到了这个数值，后来的顾客只能离去了（相当于连不上数据库）。
这里需要注意的是MAX_CONNECTIONS并不是指同时连在实例上的活动的连接，因为有些连接即使连在实例上了，也要等候协调代理服务，当前活动的连接数与活动的协调代理数相等。
当一个协调代理处理完一个应用程序后，它会被分配给其它等候的应用，相当于服务员去服务于其他等待着的顾客。
在饭店中还有一些座位是专门为服务员休息准备的（这个座位数相当于NUM_POOLAGENTS）。
当顾客渐渐散去，越来越少的时候，部分服务员（协调代理）已经无事可做，就返回这些座位（变成空闲代理）。
当这些座位也被占满了，那么再有服务员（协调代理）返回休息时，就没有可供休息的座位了（假设服务员不能坐就餐座位）。
这些服务员就只有返回员工宿舍了（相当于代理的删除）。
图1反映了这一流程。
图中实线箭头表明当前状态，虚线箭头表明将要发生的事件。
图1.代理的工作流程图
2.DB2V9.5新特性
在DB2V9.5中有一个新特性，就是MAX_CONNECTIONS和MAX_COORDAGENTS都可以被设置成AUTOMATIC。
如果你认为系统可以承受所有的连接，同时又想限制被协调代理消耗的资源，你可以只将MAX_CONNECTIONS设定为AUTOMATIC，MAX_COORDAGENTS设定为一个数值。
这时系统认为可以连到实例的连接数时无限的。
如果你对最大连接数和协调代理数都不想做限制的话，你可以将它们都设为AUTOMATIC。
如果这时MAX_CONNECTIONS设定为AUTOMATIC的数值大于MAX_COORDAGENTS设定为AUTOMATIC的数值，连接集中器也就被激活了。
而后，服务器就以刚才的两个数值之比作为参照（这里叫做集中率）按比例根据连接数来相应调整协调代理。
示例如下：
db2updatedbmcfgusingMAX_CONNECTIONS300AUTOMATIC;
db2updatedbmcfgusingMAX_COORDAGENTS100AUTOMATIC;
这时集中率为300/100=3，当连接在1到100时会创建协调代理，大于100小于301时就不会创建新的协调代理了。
再从301增加到400，又会增加100个协调代理，大于400小于601时又停止增加了……即每增加300个连接会增加100个协调代理。
当前的具体数值可以通过db2attachtoinstance_name，db2getdbmcfgshowdetail得到。
在这里允许设为AUTOMATIC有下面两种情况：
◆MAX_CONNECTIONS为AUTOMATIC而MAX_COORDAGENTS为一定值。
◆MAX_CONNECTIONS与MAX_COORDAGENTS同时为AUTOMATIC。
当然连接集中器也有一些局限性：
◆联邦数据库不支持连接集中器
◆连接集中器对使用withholdfeature的应用程序无效
◆全局临时表在事务完成时必须显式关闭，否则连接集中器就会被关闭
◆连接两阶段提交事务的连接只能用来连接两阶段提交事务的连接，同理连接一阶段提交事务的连接◆也只能用来连接一阶段提交事务的连接。
◆不能在线激活连接集中器，也就是说，需要重启实例才可生效。
如果既不想使用连接集中器，又不想限制数据库连接的数目，可以运行下面的命令：
db2updatedbmcfgusingMAX_COORDAGENTSAUTOMATIC；
db2updatedbmcfgusingMAX_CONNECTIONSAUTOMATIC；
代理和连接常见问题分析与优化
1．连接超限问题
在DB2V8，V9.1中所设置的MAX_CONNECTIONS或MAXAGENTS值比较小时，如果出现了外部连接数过多就会出现错误。
错误如清单1所示。
清单1.db2diag.log诊断日志
2008-01-15-14.30.13.090289-360I12983210A1195LEVEL:
Info
PID:
762076TID:
772PROC:
db2acd
INSTANCE:
db2inst1NODE:
000
APPID:
*LOCAL.db2inst1.080115203015
EDUID:
772EDUNAME:
db2acd
FUNCTION:
DB2UDB,DRDACommunicationManager,sqljcReceive,probe:
30
MESSAGE:
ZRC=0x8136001C=-2127167460=SQLZ_RC_NO_CONNECTION,SQLT_SQLJC
"Noconnection"
DATA#1:
String,11bytes
CCIError:
DATA#2:
unsignedinteger,8bytes
...
这时可以通过下面命令来查看当前的连接数：
清单2.查看当前的连接数
$db2listapplications
AuthIdApplicationAppl.ApplicationId
DB#of
NameHandle
NameAgents
-----------------------------------------------------------------------------
------------------------------
DB2INST1db2taskd583*LOCAL.db2inst1.080112150958
SVT_DB1
DB2INST1db2stmm582*LOCAL.db2inst1.080112150957
SVT_DB1
DB2INST1java592*LOCAL.db2inst1.080115201505
SVT_DB1
DB2INST1java572*LOCAL.db2inst1.080115201445
SVT_DB1
DB2INST1java585*LOCAL.db2inst1.080115201458
SVT_DB1
DB2INST1java565*LOCAL.db2inst1.080115201437
SVT_DB1
DB2INST1java584*LOCAL.db2inst1.080115201457
SVT_DB1
DB2INST1java590*LOCAL.db2inst1.080115201503
SVT_DB1
DB2INST1db2bp591*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–dbSVT_DB
DatabasePartition0--Active--Up1days01:
24:
44
Agents:
Currentagents:
36
Idleagents:
0
Activecoordagents:
28
Activeagentstotal:
28
Pooledcoordagents:
8
Pooledagentstotal:
8
AddressAppHandl[nod-index]AgentEDUIDPriorityTypeState
ClientPidUseridClientNmRowsreadRowswrtnLkTmOtDBName
0x0780000000DABD60522[000-00522]23150CoordInst-Act
ive655614db2inst1db2bp3757939620NotSetSVT_DB
0x07800000027A4160523[000-00523]61700CoordInst-Act
ive655614db2inst1db2stmm00NotSetSVT_DB
0x07800000027A5700524[000-00524]64270CoordInst-Act
ive655614db2inst1db2taskd00NotSetSVT_DB
0x0780000000DAD840525[000-00525]51580CoordInst-Act
ive655614db2inst1db2wlmd00NotSetSVT_DB
0x07800000027A0080526[000-00526]54150CoordInst-Act
ive655614db2inst1db2evml_003SVT_DB
0x07800000028C0080566[000-00566]108100CoordInst-Act
ive905284db2inst1java160282102NotSetSVT_DB
0x07800000027AB2C0567[000-00567]74690CoordInst-Act
...
在这里看到Idleagents值为0表明代理池中已经没有空闲代理了（State全都是Inst-Active）。
这时可以将Currentagents的值与MAXAGENTS的值的比较，或者Activeagentstotal的值与MAX_COORDAGENTS的值的比较，从而做出相应调整。
对于这种问题还可以通过分析数据库管理器的快照来作出调整：
清单4.分析数据库管理器的快照
db2getsnapshotfordbm：
...
RemoteConnectionExecutingintheDatabaseManager=58
LocalConnectionExecutingintheDatabaseManager=1
...
Agentsassignedfrompool=38
Agentscreatedfromemptypool=158
Agentsstolenfromanotherapplication=1
Highwatermarkforcoordinatingagents=60
Maxagentsoverflow=3
Hashjoinsafterheapthresholdexceeded=0
……
可以看到Maxagentsoverflow的值等于3，说明有3次生成代理数超过限制的情况。
这时会在DB2diag.log中看到前面的错误信息。
此时必须调节MAXAGENTS的值以修复当前错误。
可以将MAX_COORDAGENTS设定为与Highwatermarkforcoordinatingagents相同的值，在单分区环境下可以将MAXAGENTS设定与MAX_COORDAGENTS一样，在多分区环境（MPP）或节点内并行环境（SMP）中，根据节点数来计算出结果MAXAGENTS=（N+1）*MAX_COORDAGENTS（N为节点数）。
另一方面在MAX_COORDAGENTS不是AUTOMATIC的情况下，如果RemoteConnectionExecutingintheDatabaseManager的值与LocalConnectionExecutingintheDatabaseManager的值之和接近MAX_COORDAGENTS，这时要适当增大MAX_COORDAGENTS的值。
一般说来有这样的原则，当在连接数据库是出现内存错误时，调节如下参数：
◆在单分区并且没有节点内并行性（SMP）的情况下增大MAXAGENTS的值。
◆在多分区（MPP）或者节点内并行环境（SMP）的情况下增大MAXAGENTS或MAX_COORDAGENTS的值。
◆在连接集中器激活的情况下，增大MAX_CONNECTIONS的值。
2.连接挂起问题
还有一个与连接相关的问题：
在首次连接数据库时，连接时间总要长一些。
这是因为数据库在为首次连接分配内存，主要是缓冲池。
连接时间长短取决于操作系统的内存调用情况以及缓冲池的大小。
有时用户常常会为了提高应用性能盲目的扩大缓冲池，造成缓冲池设置得太大，甚至超过了数据库共享内存，使得实例无法为数据库分配足够的内存，在连接数据库时就会出现挂起现象。
而这时想将缓冲池设小也没办法了，因为数据库连不上，无法设置缓冲池。
这也是一个常见的问题。
遇到这种问题时，有些用户甚至被迫重建数据库。
其实这个问题可以通过设置DB2注册参数DB2_OVERRIDE_BPF来设置缓冲池的大小，从而能够再次连接数据库。
在缺省情况下（v9.1，v9.5）缓冲池的大小被设置成-2（通过selectnpagesfromsyscat.BUFFERPOOLS得到），这说明缓冲池时自动增长的，这种情况下最好不要修改缓冲池的大小，可以让DB2自动去调节。
3.常见通信错误
通常在连接数据库时还会遇到的一些与网络通信相关的错误，这些错误号如：
SQL30080，SQL30081等等。
可以用以下一些方法去尝试解决：
◆执行命令db2set–all来检查一下是否有DB2COMM=TCPIP一项，如果没有则应该添加上。
◆执行命令db2getdbmcfg|grepSVCENAME来检查SVCENAME设定的服务是否在/etc/services（UNIX）中定义了（WINDOWS是在%windir%\system32\drivers\etc\services）。
当然如果SVCENAME是一个端口号，则不用在services中定义。
（端口号应小于65536）
◆执行命令netstat–a检查输出中是否有services中定义的端口或服务在监听。
如果没有，则可能需要重启网络或机器。
◆这种问题也可能是防火墙导致的，在Linux上可以通过编辑/etc/sysconfig/iptables文件来绕过防火墙（需要root权限）。
◆在WINDOWS有时还会遇到“Nobufferspaceavailable（maximumconnectionsreached?
）”的错误消息，这种错误和DB2无关，需要增大WINDOWS的注册表参数值：
◆HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\MemoryManagement\SystemPages
如果遇到其他特殊的问题可以通过命令DB2?
sqlxxxxx来根据得到的提示去分析具体问题。
4.性能优化
调节NUM_POOLAGENTS:
对于决策支持系统，由于连接数较少，NUM_POOLAGENTS可以设为一个较小的值从而避免过多的空闲代理而浪费资源。
而对于在线事务处理系统，由于连接数较多，可以设为一个较大的值从而减少频繁创建
升级会员 