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

最新推荐文章于 2022-10-27 19:49:25 发布

mlxia

最新推荐文章于 2022-10-27 19:49:25 发布

阅读量176

点赞数

分类专栏： DB2 文章标签： IBM DB2 应用服务器活动工作

本文链接：https://blog.csdn.net/mlxia/article/details/83486670

版权

DB2 专栏收录该内容

35 篇文章 0 订阅

订阅专栏

http://www.searchdatabase.com.cn/showcontent_13734.htm

带你深入了解IBM DB2的通信与连接过程（二）

投稿

打印

MSN推荐

博客引用

大 | 中 | 小

2008-9-17

导读：本文主要介绍了连接集中器以及DB2 V9.5 新特性。

关键词：IBM DB2 通信与连接过程 DB2的代理连接集中器特性

正在加载数据...

　　连接集中器

　　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；

带你深入了解IBM DB2的通信与连接过程（二）