深入了解DB2 Universal Database进程(1)
介绍
UNIX和Linux用户经常检查运行在服务器上的进程来进行问题分析，并检查服务器上被消耗的资源。这些信息不仅对解决问题和分析资源的系统管理员有用，而且对于开发高可用性和监视DB2进程以判断什么时候执行某种行为（例如数据库重新启动）或者执行必要的服务器错误恢复（failover）的错误恢复脚本都很重要。
如果使用AIX，必须使用ps -ef命令来检查进程。在Solaris和HP-UX上，ps -ef只为所有的服务器端进程（例如agents、loggers、page cleaners和 prefetchers）显示db2sysc进程（主要的DB2引擎进程）。如果你使用Solaris或者HP-UX，能使用/usr/ucb/ps -axw命令看到这些进程。这些版本的ps命令都可以在Linux上工作。
在运行DB2 Universal Database客户端或服务器软件的计算机上执行这个命令时，可以看到列出了多个DB2进程。本文的目的是说明这些进程并解释它们是做什么的以及什么时候运行。通过阅读本文你能了解DB2的每个进程，当你看到这些进程时能了解DB2正在执行什么操作。
注意：在DB2中进程是怎样执行的对于Windows和Linux、UNIX环境有稍微的不同。在Windows中，只有一个进程（db2sysc），在它下面每个引擎可分配单元（EDU）作为一个线程执行。尽管本文讨论进程，但是在Windows环境中应该认为它们是线程。在Windows任务管理器中你能够看到每个实例的db2sysc进程（db2syscs.exe）。其它的Windows服务/进程也可以显示，本文我们将解释它们是什么。
警告：不要在正常的DB2环境中直接干涉DB2进程。在Linux或UNIX中使用kill -9命令删除DB2进程可能会引起DB2的不正常的行为。如果删除进程将导致整个DB2实例停止。本文中的目的是了解这些进程而不是直接维护它们。
为什么要查看DB2进程
我们的个人经验已经显示了这些知识的价值，我们拜访的客户也向我们询问这类信息。看看下面的真实的情况，看看你自己如何检查系统上运行的DB2进程来解决问题的：
情况1：罕见的缓冲池页面清除
某个运行电子商务网站并使用DB2作为数据库服务器的客户报告说，在一天的多个时段数据库响应应用程序的时间很长。在这些时期数据库快照没有显示发生了什么不正常的行为。通过检查其中一个时段进程的CPU使用率，可以发现I/O清除器（db2pclnr）消耗了超过90％的CPU时间。接下来通过查看I/O清除进程触发器并适当地调整它们，我们消除了这种情况，该电子商务站点的处理能力提高了50％以上。
情况2：真实的情况
虽然拜访了某个IBM业务伙伴并执行了一些DB2性能调整，但是我们仍然遇到了普通的响应时间延缓。应用程序列表命令没有显示任何在这个时候不正常的进程。在取得DB2快照前，我们查看了DB2服务器上运行的DB2进程，发现db2rebal进程正在运行。在给DMS表空间添加一个容器的时候，该进程用于执行再次数据均衡。该客户承认那一天它给一个包含40GB表的表空间添加了一个容器。当重新均衡完成后，查询的响应速度返回到正常情况。
看看通知和诊断日志管理通知日志和诊断日志（db2diag.log）是系统管理员用于了解数据库活动和功能的重要工具。正常情况下它们包含DB2进程的信息，下面的例子显示了一个db2diag.log的条目：
2000-03-06-11.53.18.001160 Instance:myInst Node:000 PID:78121(db2agent (TEST)) TID:352 Appid:*LOCAL.payroll.000306140834lock_manager sqlplrq Probe:111 Database:TEST DIA9999E An internal return code occurred. Report the following:"0xFFFFE10E".
在这个例子中，消息来源的进程ID号是78121。这个进程的名字是db2agent，并且它连接了叫做TEST的数据库。了解每个进程在做什么能帮助你了解系统管理通知日志和db2diag.log的内容。
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：每个实例和每个活动数据库的进程
