介绍
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.000306140834
lock_manager sqlplrq Probe:111 Database:TEST
DIA9999E An internal return code occurred. Report the following:
"0xFFFFE10E".
在这个例子中，消息来源的进程ID号是78121。这个进程的名字是db2agent，并且它连接了叫做TEST的数据库。了解每个进程在做什么能帮助你了解系统管理通知日志和db2diag.log的内容。