代理和连接常见问题分析与优化

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 &#101xecuting in the Database Manager = 58

Local Connection &#101xecuting 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 &#101xecuting in the Database Manager 的值与 Local Connection &#101xecuting 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中的代理新特性，并能够利用这些新特性更好地优化数据库。