DB2进程的模型
代理
代理可以认为是一个"工作程序"，它执行所有的应用程序需要的数据库操作。有两种类型的DB2代理：
◆ 协调程序代理（db2agent）
协调程序代理代表应用程序协调工作，并且使用进程间通讯（interprocess communication，IPC）或者远程通讯协议与其它的代理通讯。所有的客户端应用程序连接请求，无论是本地的或远程的，都会分配一个相应的协调程序代理。
◆ 子代理（db2agntp）
当允许intra_parallel数据库管理器配置参数时，协调程序代理把数据库请求分配给子代理（db2agntp）。这些代理为应用程序执行请求。一旦建立了协调程序代理，它就通过协调执行数据库请求的子代理，代表应用程序处理所有的数据库请求。
当某个代理或者子代理完成了自己的工作时它就变为空闲的。当某个子代理变为空闲时，它的名字从db2agntp变为db2agnta。
例如：
db2agntp是活动的子代理，它正在为协调程序代理执行工作。这些进程只有允许内部分区并行性（intra-partition parallelism）时才存在。
db2agnta是空闲的子代理，它在过去的某个时候被协调程序代理使用。空闲代理位于代理池中。这些代理对于来自代表客户端程序的协调程序代理的请求是可用的。可用的代理数量依赖于数据库管理器的配置参数maxagents和num_poolagents。
本文的后面一部分将讲解其它类型的代理（例如并行回复代理，db2agnsc）。下面是显示DB2进程模型的两个图表。
图1：没有连接集合的DB2进程模型（对于无分区的数据库）
图1中的每个圆圈代表引擎可分配单元（EDU），它是Linux/UNIX平台上的进程，Windows中的线程。
应用程序A（App A）和B（App B）都是运行在DB2服务器上的本地应用程序。当这些应用程序请求一个到数据库的CONNECT时，db2ipccm监听进程建立数据库管理器和应用程序之间的通讯。db2ipccm也使用一个协调程序代理EDU（db2agent）工作，它直接连接客户端应用程序来建立客户端应用程序和代理之间的共享内存通讯。一旦建立了该通讯，本地客户端的应用程序就连接到数据库了。
应用程序C（App C）是一个远程应用程序，它位于DB2服务器外的另一台计算机上。远程客户端通过db2tcpcm监听进程建立TCP/IP通讯。接着该db2tcpcm与db2agent一起工作，它成为应用程序的协调程序代理并把连接传递到这个代理。在这以后，协调程序代理联系远程客户端应用程序并且连接到数据库了。
图2：没有连接集合的DB2进程模型（对于分区数据库）
图2与图1相似，但可用于分区的数据库。Node0000和Node0001代表两个不同的计算机，数据库的分区分别在它们上面。该进程与它们之间的交互作用与图1中的相同，但是有一些进程只能用于这样的环境。例如db2fcmd即快速通讯管理器（Fast Communication Manager）进程，它用于管理不同分区之间的通讯。下一部分的表格更仔细地说明了其它用于分区数据库的进程。
各个进程
下表按照功能列举了每个实例、每个数据库的所有DB2进程。注意下表中的有些进程没有按字母次序，而是基于功能分组。
表1：每个实例的进程--没有连接、没有活动的数据库
表2：每个实例和每个连接的进程
表3：每个实例和每个活动数据库的进程
表4：按功能分类的其它进程
表5：一些常用的执行文件
表6：其它的Windows服务/进程
示例
下面的例子显示了在AIX上运行ps -ef命令时可能得到的输出：
| 在db2start后： root 49504 1 0 13:13:07 - 0:00 db2wdog db2inst1 22142 49180 0 13:13:10 - 0:00 db2gds db2inst1 43072 49180 0 13:13:17 - 0:00 db2syslog db2inst1 45294 74134 0 12:12:43 pts/2 0:00 /usr/bin/ksh db2inst1 49180 49504 0 13:13:10 - 0:00 db2sysc db2inst1 55920 49180 0 13:13:19 - 0:00 db2resync db2inst1 59012 22142 0 13:13:19 - 0:00 db2srvlst db2inst1 60680 49180 0 13:13:17 - 0:00 db2ipccm |
数据库管理器配置文件有下面的设置，他们影响到你最初看到的进程：
| Max number of existing agents (MAXAGENTS) = 200 Agent pool size (NUM_POOLAGENTS) = 100(calculated) Initial number of agents in pool (NUM_INITAGENTS) = 0 |
因为NUM_INITAGENTS为0，在db2start时没有"db2agent（idle）"进程显示。如果在db2agent前把NUM_INITAGENTS设置为5，在运行db2start后将显示下面的额外进程：
| db2inst1 35542 59814 0 16:25:57 - 0:00 db2agent (idle) db2inst1 43096 59814 0 16:25:57 - 0:00 db2agent (idle) db2inst1 49628 59814 0 16:25:57 - 0:00 db2agent (idle) db2inst1 58170 59814 0 16:25:57 - 0:00 db2agent (idle) db2inst1 64012 59814 0 16:25:57 - 0:00 db2agent (idle) |
在连接到数据库SAMPLE后（NUM_INITAGENTS仍然为0）：
| root 49504 1 0 13:13:07 - 0:00 db2wdog db2inst1 25844 35124 0 16:04:50 - 0:00 db2pfchr db2inst1 35124 65638 0 16:04:17 - 0:00 db2gds db2inst1 35540 35124 0 16:04:50 - 0:00 db2loggr (SAMPLE) db2inst1 41940 65638 0 16:04:19 - 0:00 db2resync db2inst1 45058 35124 0 16:04:50 - 0:00 db2pfchr db2inst1 49300 35124 0 16:04:19 - 0:00 db2srvlst db2inst1 49626 35124 0 16:04:50 - 0:00 db2dlock (SAMPLE) db2inst1 55852 65638 0 16:04:17 - 0:00 db2ipccm db2inst1 58168 35124 0 16:04:50 - 0:00 db2loggw (SAMPLE) db2inst1 59048 35124 0 16:04:50 - 0:00 db2pfchr db2inst1 64010 55852 0 16:04:50 - 0:00 db2agent (SAMPLE) db2inst1 65638 22238 0 16:04:17 - 0:00 db2sysc db2inst1 70018 35124 0 16:04:50 - 0:00 db2pclnr db2inst1 72120 35124 0 16:04:51 - 0:00 db2event (DB2DETAILDEADLOCK) db2inst1 74198 65638 0 16:04:17 - 0:00 db2syslog db2inst1 74578 1 0 16:04:47 - 0:00 /home/db2inst1/sqllib/bin/db2bp 50112C14631 5 |
在连接到SAMPLE数据库后，出现了"db2agent（SAMPLE）"进程。这个进程显示实际上有一个到SAMPLE数据库的连接。如果我们运行下面的命令：
| db2 connect reset |
db2agent（SAMPLE）将变成db2agent（idle）。这是因为NUM_POOLAGENTS设置为大于0，这意味着代理仍然分配在缓冲池中，虽然它时空闲的。如果NUM_POOLAGENTS设置为0，那么在"connect reset"后，就没有db2agent进程运行了。
SAMPLE数据库的数据库配置文件有下面的设置：
| Number of asynchronous page cleaners (NUM_IOCLEANERS) = 1 Number of I/O servers (NUM_IOSERVERS) = 3 |
注意有三个db2pfchr进程，他们与NUM_IOSERVERS的值相对应，有一个db2pclnr进程与NUM_IOCLEANERS的值相对应。
总结
还有许多其它的进程可能出现或者不出现，这依赖于不同的DB2行为和配置设定。我们演示了怎样调查哪个进程正在运行、这些进程显示什么信息、以及它们受到数据库设置怎样的影响的示例。现在你能使用这些知识提高管理DB2数据库的能力。
