带你深入了解IBM DB2的通信与连接过程解析.docx

1、带你深入了解IBM DB2的通信与连接过程解析带你深入了解IBM DB2的通信与连接过程Alizze 时间:2008年08月04日 字 体: 大 中 小关键词:集中器连接数应用程序管理器最大? 本文详细描述了 DB2? Universal Database?（DB2 UDB）代理的工作原理以及连接集中器的特性，并对 DB2 连接上常见的问题及代理的优化作了详细的分析。希望通过本文让用户能够了解 DB2 的连接机制和客户端与服务器端的交互作用，可以解决在实际的商业环境中遇到的性能问题。 简介 ? DB2 的代理 (agent) 是位于 DB2 服务器中的服务于应用程序请求的一些进程或线程。当有外

2、部应用程序连接至 DB2 实例提出访问请求时，DB2 的代理就会被激活去应答这些请求。一般 DB2 的代理被称为工作代理，工作代理大概有三种类型：空闲代理、活动的协调代理、子代理。 ? 空闲代理：指的是没有任何任务的代理。这种代理不服务于任何远程连接也不服务于本地连接，处于一种备用或待命状态。 ? 活动的协调代理：指的是处于工作状态的代理，每一个外部应用程序产生的数据库活动连接的都有一个活动协调代理来为它服务。 ? 子代理：指的是接受协调代理分发出来的工作的下一级代理。在 DB2 V95 以前，只有在多分区环境 (MPP) 或节点内并行环境 (SMP) 下才存在子代理，在 DB2 V95 中所

3、有环境中都可能存在子代理。 ? 在 DB2 服务器中有一个代理池，当实例刚启动后这里便有一些代理（其数量取决于实例参数 NUM_INITAGENTS）。在没有任何数据库连接时，它们处于待命状态，就是空闲代理。而当有外部程序连接至数据库时，这些代理开始得到命令去服务于这些新建的连接，这时它们就变成了活动的协调代理。这些协调代理再将请求逐步细分，分配给下一级代理即子代理去处理。如果当前的代理都已经在工作了，同时又来了新的请求，数据库管理器会产生一个新的代理去应答。当事务处理完毕而且数据库? 连接断开后，协调代理要么返回代理池变回空闲代理，要么就自动消失了（取决于实例参数 NUM_POOLAGENT

4、S）。这就是一个代理的生命周期。 相关的配置参数 ? 通过执行 DB2 get dbm cfg 可以看到以下几个和代理相关的实例参数：MAXAGENTS，NUM_POOLAGENTS，NUM_INITAGENTS，MAX_COORDAGENTS，MAX_CONNECTIONS，MAXCAGENTS。下面对它们做一下简要介绍： ? MAXAGENTS：这个参数为当前实例中全部代理的数量，包括协调代理，空闲代理和子代理之和。不过这个参数在 DB2 V95 中已经不再使用了。 ? NUM_POOLAGENTS：这个参数用来控制代理池中的空闲代理的数量。当活动的代理完成工作返回代理池变成空闲代理时，如

5、果数量超过了这个参数，那么这个代理就会自动消失了。注意：在连接集中器激活的情况下，代理池中的空闲代理数目在某一时刻可能会超过 NUM_POOLAGENTS 的大小，以应对突发的高密度连接。 ? NUM_INITAGENTS：这个参数就是前面提到的在实例刚刚启动时便生成的一些空闲代理的数目。这是为了提高性能，因为这些代理可以随时变成协调代理去应答外部应用请求，而不用临时再生成新的代理。 ? MAX_COORDAGENTS：这个参数决定了在实例中在同一时刻最大的协调代理的数目 ( 在多分区环境指的是一个节点上的最大协调代理数 )。 ? MAX_CONNECTIONS：这个参数决定了允许连接至一个实

6、例的最大的连接数 ( 在多分区环境指的是一个节点上的最大连接数 )。 ? MAXCAGENT：这个参数决定了实例中的令牌的数量，一个协调代理只有得到了令牌才能去服务于应用程序。当没有得到令牌时，协调代理只能等候。不过这个参数在 DB2 V95 中也已经取消了。 ? 还有一个连接参数 MAXAPPLS 可以通过 db2 get db cfg for database_name 得到，它是一个数据库级别的参数，这个参数决定了同时连接至一个数据库的最大连接数。在一个实例下的所有数据库的 MAXAPPLS 值之和不能超过实例参数MAX_CONNECTIONS。 连接集中器 1. 基本原理 ? 从 DB

7、2 V8 开始，DB2 实例中有一个叫做连接集中器的特性，可以用来优化数据库的连接。缺省情况下，在实例创建的时候，MAX_CONNECTIONS 与 MAX_COORDAGENTS 的值是一致的。这个时候每一个协调代理唯一地服务于一个连接。比如说有 1000 个连接就要有 1000 个协调代理为之服务。这对服务器是一个很大的负担，因为每一个代理都要消耗一定的资源。而当我们将 MAX_CONNECTIONS 的值设定的比 MAX_COORDAGENTS 大，这时 DB2 的连接集中器就被激活了。它允许多个连接对应于一个代理。 ? 连接集中器的功能与 DB2 CONNECT 中的连接池相似。不过连

8、接集中器比连接池的优点在于它能够重用外部连接，即多个排队的应用程序可以重复使用一个存在的连接，而连接池则需要先删除再重建一个连接去服务于一个新的应用程序。在连接集中器中每个协调代理并不唯一地服务于一个连接，当某个外部连接断开后，协调代理被分配给其他连接。这样。同时允许更多的连接连到数据库，并且减少了每个连接的内存消耗，避免了频繁的删除和创建代理所带来的系统开销。下面是连接集中器的具体工作原理： ? 首先将 MAX_CONNECTIONS 的值设定的大于 MAX_COORDAGENTS 去激活连接集中器。在连接集中器中代理被分成逻辑代理和工作代理。逻辑代理与外部应用程序对应，它并不对应与某个特定

9、的引擎分配单元 (EDU)。工作代理和前面定义的一样，是具体的引擎分配单元。当逻辑代理多于工作代理时连接集中器就被激活了。当有多个连接同时连接到服务器时，连接被一一分配给各个逻辑代理。逻辑代理再去请求工作代理的服务。 ? 比方说，代理池是一个饭店，在饭店里通常都是顾客多于服务员。刚开始，还没有顾客 ( 相当于外部应用 ) 的时候。有一些值班的服务员在饭店里待命（相当于实例启动时在代理池中创建的空闲代理 NUM_INITAGENTS）。一旦来了应用请求（顾客），调度程序（相当于领班）就去安排服务员开始工作，服务员就开始忙起来去招呼顾客。这时服务员的角色相当于协调代理。她们接待完顾客后便将菜单传达

10、给厨师和小工 ( 相当于子代理 )。而当顾客越来越多，超过了最初的值班服务员数量。服务器就生成新的代理来服务于这些应用，就好像是从员工宿舍叫来更多的服务员来工作。当在场服务员数达到了一个数目 (MAX_COORDAGENTS)，饭店的所有服务员都在工作了，没有其他的在编服务员了。这时新来的顾客 ( 外部应用 ) 只能坐在座位上等候了。MAX_CONNECTIONS 在这里相当于饭店里的总的就餐座位数，当顾客数目 ( 外部应用 ) 达到了这个数值，后来的顾客只能离去了（相当于连不上数据库）。 ? 这里需要注意的是 MAX_CONNECTIONS 并不是指同时连在实例上的活动的连接，因为有些连接即

11、使连在实例上了，也要等候协调代理服务，当前活动的连接数与活动的协调代理数相等。当一个协调代理处理完一个应用程序后，它会被分配给其它等候的应用，相当于服务员去服务于其他等待着的顾客。在饭店中还有一些座位是专门为服务员休息准备的 ( 这个座位数相当于 NUM_POOLAGENTS)。当顾客渐渐散去，越来越少的时候，部分服务员 ( 协调代理 ) 已经无事可做，就返回这些座位（变成空闲代理）。当这些座位也被占满了，那么再有服务员 ( 协调代理 ) 返回休息时，就没有可供休息的座位了 ( 假设服务员不能坐就餐座位 )。这些服务员就只有返回员工宿舍了 ( 相当于代理的删除 )。图 1 反映了这一流程。图中

12、实线箭头表明当前状态，虚线箭头表明将要发生的事件。 ? ? 图 1. 代理的工作流程图 2. DB2 V9.5 新特性 ? 在 DB2 V9.5 中有一个新特性，就是 MAX_CONNECTIONS 和 MAX_COORDAGENTS 都可以被设置成 AUTOMATIC。如果你认为系统可以承受所有的连接，同时又想限制被协调代理消耗的资源，你可以只将 MAX_CONNECTIONS 设定为 AUTOMATIC， MAX_COORDAGENTS 设定为一个数值。这时系统认为可以连到实例的连接数时无限的。如果你对最大连接数和协调代理数都不想做限制的话，你可以将它们都设为 AUTOMATIC。如果这时

13、 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 时会创建协调代理，大于

14、 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 同时为 AUTO

15、MATIC。 当然连接集中器也有一些局限性： ? 联邦数据库不支持连接集中器 ? 连接集中器对使用 withhold feature 的应用程序无效 ? 全局临时表在事务完成时必须显式关闭，否则连接集中器就会被关闭 ? 连接两阶段提交事务的连接只能用来连接两阶段提交事务的连接，同理连接一阶段提交事务的连接也只能用来连接一阶段提交事务的连接。 ? 不能在线激活连接集中器，也就是说，需要重启实例才可生效。 ? 如果既不想使用连接集中器，又不想限制数据库连接的数目，可以运行下面的命令： ? db2 update dbm cfg using MAX_COORDAGENTS AUTOMATIC； ? d

16、b2 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: db2

17、inst1 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 :

18、 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 DB2

19、INST1 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 *LOCA

20、L.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 命令窗口 ) 的一

21、个连接。可以看到这些连接都连到了数据库 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 Addres

22、s 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

23、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 db2e

24、vml_ 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 agen

25、ts 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 =

26、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

27、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 t

28、he Database Manager 的值之和接近 MAX_COORDAGENTS，这时要适当增大 MAX_COORDAGENTS 的值。 ? 一般说来有这样的原则，当在连接数据库是出现内存错误时，调节如下参数： ? 在单分区并且没有节点内并行性 (SMP) 的情况下增大 MAXAGENTS 的值。 ? 在多分区 (MPP) 或者节点内并行环境 (SMP) 的情况下增大 MAXAGENTS 或 MAX_COORDAGENTS 的值。 ? 在连接集中器激活的情况下，增大 MAX_CONNECTIONS 的值。 2. 连接挂起问题 ? 还有一个与连接相关的问题：在首次连接数据库时，连接时间总要长一些。这是因为数据库在为首次连接分配内存，主要是缓冲池。连接时间长短取决于操作系统的内存调用情况以及缓冲池的大小。有时用户常常会为了提高应用性能盲目的扩大缓冲池，造成缓冲池设置得太大，甚至超过了数据库共享内存，使得实例无法为数据库分配足够的内存，在连接数据库时就会出现挂起现象。而这时想将缓冲池设小也没办法了，因为数据库连不上，无法设置缓冲池。这也是一个常见的问题。遇到这种问题时，有些用户甚至被迫重建数据库。其实这个问题可以通过设置 DB2 注册参数 DB2_OVERRIDE_BPF 来设置缓冲池的大小，从而能