环境:
产品：DB2 UDB
平台：跨平台
版本：V9
问题描述:
随着 DB2 UDB V9 的正式发布，已经有不少用户开始体验 V9 给我们带来的新功能、新特性了。也许细心的用户会发现，在连接数据库后，用“LIST APPLICATIONS”命令查看应用程序对数据库的连接情况，V9 会比以前的版本多出来两个进程，db2stmm 和 db2taskd，如下所示：
$ db2 list applications
Auth Id Application Appl. Application Id DB # of
Name Handle Name Agents
-------- ------------ ---------- -------------------------------- -------- -----
DB2V9I1 db2taskd 927 *LOCAL.DB2.061221070953 SAMPLE 1
DB2V9I1 db2stmm 926 *LOCAL.DB2.061221070952 SAMPLE 1
DB2V9I1 db2bp 923 *LOCAL.db2v9i1.061221070940 SAMPLE 1
那么这两个进程是如何产生的？它们有什么作用？又会引起一些什么影响呢？
解答:
在DB2 V9.1 中新增了两个 DB2 代理程序 db2stmm 和 db2taskd：
db2stmm 代理程序是 DB2 V9.1 中新增的自调整内存功能的一部分。
db2taskd 代理程序是分发后台数据库任务的内部守护程序。
当数据库启动后，这两个新的代理程序（db2stmm 和 db2taskd）会一直保持与数据库的连接，因此 LIST APPLICATIONS 命令的输出中会列出除了用户连接以外的这两个代理程序。
但如果以互斥方式激活数据库，则它们会处于不活动状态。如：
$ db2 connect to sample in exclusive mode
Database Connection Information
Database server = DB2/AIX64 9.1.0
SQL authorization ID = DB2V9I1
Local database alias = SAMPLE
$ db2 list applications
Auth Id Application Appl. Application Id DB # of
Name Handle Name Agents
-------- ------------ ---------- -------------------------------- -------- -----
DB2V9I1 db2bp 1079 *LOCAL.db2v9i1.061221100533 SAMPLE 1
如果已配置了用于控制可连接实例的最大应用程序数的MAX_CONNECTIONS 参数来限制应用程序连接数，那么这两个代理进程的出现，使得您可能需要适当的调整您的 MAX_CONNECTIONS，以确保在迁移至 DB2 V9.1 之后，可用的连接数能保持稳定。
这两个代理程序都是数据库启动的系统应用程序。它们会出现在数据库系统监视器中。因此，如果使用监视LIST APPLICATIONS 命令输出的脚本或工具，则可能需要修改此脚本或工具以说明这两个新增的代理程序。
