深入了解DB2 Universal Database进程（1）_DB2教程

　　介绍　　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进程 123456下一页　　我们的个人经验已经显示了这些知识的价值，我们拜访的客户也向我们询问这类信息。看看下面的真实的情况，看看你自己如何检查系统上运行的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".

上一页123456下一页　　在这个例子中，消息来源的进程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进程模型（对于无分区的数据库）上一页123456下一页　　图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：每个实例和每个连接的进程上一页123456下一页

　　表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

上一页123456下一页　　因为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数据库的能力。上一页123456