DB2 通用数据库进程全接触

简介

UNIX 和 Linux 用户通常会检查运行在其服务器上的进程，以执行问题分析及检查服务器中消耗的资源。该信息不仅对执行问题和资源分析的管理员有用，而且对于那些开发高度可用性和故障转移脚本（这些脚本监控 DB2 进程，以确定何时需要进行诸如数据库重新启动或服务器故障转移之类的操作）的人也很有用。

如果您正在使用 AIX，则可以使用命令 ps -ef 检查进程。在 Solaris 和 HP-UX 上， ps -ef 将只显示所有服务器端进程（例如：代理程序、记录器、页面清除程序和预取程序）的 db2sysc 进程（主 DB2 引擎进程）。如果您正在使用 Solaris 或 HP-UX，利用命令 /usr/ucb/ps -axw 您可以看到这些服务器端进程。这两种版本的 ps 命令都可以在 Linux 上使用。

当在运行 DB2 通用数据库客户机或服务器软件的计算机上执行该命令时，您可能会看到列出了几个 DB2 进程。本文的目的是记录这些进程，并且解释它们的作用以及它们何时可能会运行。尽管手册 DB2 UDB V8 Administration Guide - Performance 的第 2 章记录了大多数重要的进程，但该列表并不完整。通过阅读本文，您将会理解每个 DB2 进程，当您看到那些进程时，您会开始明白 DB2 正在执行什么操作。

请注意，DB2 在 Windows 上工作方式的实现与基于 Linux 和 UNIX 环境的实现稍有不同。在 Windows 中，只有一个进程（db2sysc），在该进程下的每个引擎分派单元（engine dispatchable unit，EDU）都被作为线程来实现。尽管本文讨论的是进程，但是在 Windows 环境中应当把它们看成线程。通过 Windows 任务管理器（Task Manager），您将能够看到每个实例的 db2sysc 进程（db2syscs.exe）。还将显示其它 Windows 服务／进程，我们将在本文中解释它们是什么。

警告！请勿直接干预正常 DB2 环境中的 DB2 进程。在 Linux 或 UNIX 中利用 kill -9 命令杀死 DB2 进程可能会导致 DB2 出现异常行为。例如，杀死 db2sysc 进程将使整个 DB2 实例停止运行。本文旨在帮助您理解进程，而不是直接操作它们。

为什么研究 DB2 进程？

我们的个人经验已表明这方面的知识很有价值，并且我们拜访的客户也向我们寻求这类信息。还不相信吗？看一看下面的实际方案，并且亲眼看看如何通过检查在系统上运行的 DB2 进程来解决问题：

方案 1：罕见的缓冲池页面的清除

一个运行电子商务（eCommerce）站点并使用 DB2 作为数据库服务器的客户报告说，在一整天里，数据库对应用程序请求的响应时间会不时地变得很长。数据库快照未显示当时有任何异常发生。通过检查服务器上进程在其中某一时刻的 CPU 使用情况，我们可以确定 I/O 清除程序（db2pclnr）消耗了超过 90％ 的 CPU 时间。随后通过研究 I/O 清除程序触发器并对其进行相应的调优，我们消除了这种情况，使得电子商务站点每天可以处理的吞吐量提高了 50％ 以上。

方案 2：真相大白

在拜访 IBM 的一家业务合作伙伴以进行一些 DB2 性能调优工作时，我们碰到了查询响应时间全面延长的问题。除了常规的程序之外，显示应用程序列表的命令并未显示当时有任何其它程序在运行。在获得 DB2 快照之前，我们看了一下运行在 DB2 服务器上的 DB2 进程，发现 db2rebal 进程正在运行。当将某个容器添加到 DMS 表空间时，就会使用该进程执行数据的重新均衡工作。客户“承认”，那天的早些时候他将一个容器添加到了包含 40 GB 表的表空间。一旦重新均衡工作完成，查询响应时间恢复如初。

揭开通知和诊断日志的庐山真面目

管理通知日志和诊断日志（ 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:SAMPLE
DIA9999E　An internal return code occurred. Report the following:
"0xFFFFE10E".

在该示例中，消息来自进程标识号为 78121 的进程。该进程的名称是 db2agent，并与名为 TEST 的数据库相连。理解进程的功能有助于您了解管理通知日志和 db2diag.log 中各项的意义。

DB2 进程模型

尽管 DB2 Administration Guide - Performance 手册中介绍了 DB2 进程模型，但是本文还是将对其做一下简要概述。首先说明 代理程序（agent）的概念。

代理程序

代理程序可被认为是一个代表应用程序执行所有数据库操作的“工作程序”。DB2 代理程序主要有两种：

协调程序代理程序（Coordinator Agent）（db2agent）

协调程序代理程序代表应用程序协调工作，并使用进程间通信（IPC）或远程通信协议与其它代理程序进行通信。所有来自客户机应用程序的连接请求，无论是本地还是远程的，都分配了相应的协调程序代理程序。

子代理程序（Subagent）（db2agntp）

如果启用了 intra_parallel 数据库管理器配置参数，协调程序代理程序就会把数据库请求分发给子代理程序（db2agntp）。这些代理程序执行应用程序的请求。一旦创建了协调程序代理程序，通过协调对数据库执行请求的子代理程序（db2agent），协调程序代理程序代表其应用程序处理所有数据库请求。

当某个代理程序或子代理程序完成其任务时，它就转为空闲状态。当子代理程序处于空闲状态时，其名称从 db2agntp 变为 db2agnta。

例如：

db2agntp进程是活动的子代理程序，它们当前正在执行协调程序代理程序的工作。仅当启用了分区内并行性时，这些进程才存在。

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 进程。请注意，下表中的一些进程并不是按照字母顺序列出的，而是根据功能进行分组的。如果您希望以字母顺序查找进程，请参阅下面的 表 7。

表 1. 每个实例的进程 — 无连接，无活动的数据库