(转)性能调优和问题诊断最佳实践，第 1 部分

DB2 最佳实践

原文：https://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0903perfbp1/

性能调优和问题诊断最佳实践，第 1 部分

性能调优从配置和监控开始

developerWorks 中国网站编辑团队
2009 年 3 月 12 日发布

WeiboGoogle+用电子邮件发送本页面

1

系列内容：

此内容是该系列的一部分：DB2 最佳实践

内容提要

大多数 DB2 系统都经过了性能的演变。首先，不论出于硬件还是软件的观点，该系统首先要能被配置。在多数情况下，这将成为系统在实施后如何运行的基础。其次，系统一经发布，勤勉的数据库管理员（DBA）将监控系统的性能，来监测任何可能的开发问题。如果发现任何问题，我们就进入下一个阶段 - 故障诊断阶段。每个阶段都是基于上一阶段，如果没有适当的准备，我们极有可能需要处理比较困难的问题。

本文介绍了 DB2 系统性能的最优方法。我首先涉及到一些有助于我们确保良好软硬件性能的重要原则。然后我们讨论多种在操作和故障诊断的情况下，有助于我们了解系统性能的监控方法。最后，尽管我们做了最好的准备，性能问题仍然可以降临到我们身上，我们讨论如何逐步地处理它们，并有条不紊的进行。

简介

任何形式的性能问题都将严重影响并降低一个系统对你组织的价值、削弱业务能力、服务中断、以及增加管理开销。所有这些都会提升总的拥有成本。缺乏对系统配置的基本原则，监视和性能故障诊断可能导致不同程度的性能低下，并且降低对于组织的价值。

因此，在前期花些时间去考虑基本的配置指导方针和建立健全的系统监控这样的做法，将使你对处理许多可能出现的典型性能问题，有充分的准备。并使数据服务器得以高性能运行，以提高投资回报率。

第一步：从配置上实现性能良好

像 InfoSphere 平衡的仓库（BW）这类的 DB2 部署类型，或者那些在 SAP 系统之内的系统，配置都是高度确定的。在 BW 案例中，像 CPU 个数、内存对 CPU 的比率、硬盘的个数和配置这样的硬件因素，以及在预先指定版本的基础上，详尽的测试，以确定最优配置。在 SAP 的案例中，硬件配置并不是精确指定的，不过却有许多可用的配置样本。此外， SAP 最佳实践对 DB2 的配置提供了建议值。如果您正在使用它们其中之一的 DB2 系统的话，那么这些系统都提供了经过良好测试的配置指南。你通常应该利用它们对于更普通的经验法则的优势。

我们来考虑一个建议系统，这个系统不同于 BW，我们并没有有一个详细的硬件配置。虽然深入研究系统配置已经超出了本文的范畴，但是这儿有一些基本的配置指南只需要我们花时间去理解和应用。我们的目的是找出几个能让系统拥有良好性能的关键配置决定。

硬件配置

对于系统性能，CPU 的能力是在配置中一个主要的独立变量。因为所有其它的硬件配置向来取决于它，很难预测完成一个特定工作量需要的 CPU 能力。在商务智能（BI）环境下，我们可以合理地估算出每个处理器内核 200-300GB 的原始数据。对于其它的环境，一个健全的做法是基于一个或者多个 DB2 系统估算总的 CPU 需求。例如一个新系统需要处理 50% 的用户，每个用户运行的 SQL 的复杂度类似一个现有系统，可以合理地假设需要增加超过 50% 的 CPU 能力。同样，要预测 CPU 使用的其它因素改变，如不同的吞吐量要求，更多或更少的触发器或者参考完整性，等… 都应该被考虑到。

一旦我们对 CPU 需求有了很好的认识，就能利用已有信息进行开发，硬件配置的其它方面也会开始整理就绪。显然我们必须考虑到该系统的所需的磁盘容量在千兆字节或 TB，最重要的因素就在 I / O 的每秒（ IOPS）的性能，或以兆字节每秒的数据传输。实际上，这取决于涉及多少个单独的磁盘。

这是为什么呢？虽然 CPU 的发展在过去十年在速度上有了惊人的增长，然而磁盘的发展却更多的在它们的能力和成本上。虽然在磁盘搜索时间和传输率上已经有了提高，但是仍然无法更上 CPU 的速度。因此为了达到现代的系统总体性能需求，使用多个磁盘比之前任何时候都要重要，尤其是对于那些需要驱动繁重随机磁盘 I/O 的系统。很多时候，诱惑来自于使用最低的磁盘数目来存放所有数据的系统，然而这通常会导致非常差的性能。

在使用 RAID 存储的情况，或者单个可选址驱动，凭经验估计合理的配置是最少 10 到 20 个磁盘每个处理器内核。对于存储服务器，有一个类似的推荐值，不过有一点需要额外的小心。存储服务器在分配空间的时候更着眼于而容量非吞吐量。了解数据库存储的物理布局，对于确保不会出现逻辑分开的存储由于疏忽发生物理重叠的现像来说，是一个非常好的主意。例如，对于一个 4-way 的系统应来说，该有 8 组每组 8 个驱动。然而，如果 8 组共享同样的 8 个底层驱动，配置的吞吐量将受到非常严重的降低。参见 <insert storage BP paper reference here> 和 <insert physical database design BP paper reference here>

更多信息请参见存储配置最佳实践。

为 DB2 事务日志分配专门的非共享的磁盘是很好的实践。这因为日志的 I/O 特性与 DB2 容器有很大的不同。日志 I/O 与其它类型的 I/O 的竞争能导致日志成为一个瓶颈，尤其是那些有大量行写入行为的系统。

通常， 一对 RAID-1 磁盘能够提供应每秒高达 400 个的事务合理的写负载提供日志吞吐量。如果有更大的吞吐率，或更大量的日志（例如，大批插入）就需要更大的日志吞吐量，这可以通过在 RAID-10 配置中添加硬盘来提供，并通过一个写入高速缓存磁盘控制器连接到系统中。下面的故障诊断章节会讲述如果发生日志瓶颈怎么办。

由于 CPU 和磁盘有效的操作在不同的时间尺度（纳秒 VS 微秒）我们需要分离它们以获得合理的性能。这就是内存来发挥的作用。在一个数据库系统中，内存的主要作用是避免 I/O，归结为一点，拥有更多内存的系统能工作得更好。幸运的是，在过去几年中内存的成本已经有了显著的下降，并且系统拥有几十到上百 GB 的内存已经不在罕见了。通常，对于大多数应用程序每个处理器内核拥有 4 到 8GB 内存是比较合适的。

AIX 配置

为了达到比较好的性能，有一些相关参数需要调整。我们是假定 AIX 系统是 5.3 或者更高版本来给的这些建议。此外如果在你的系统中已经有了一些特定的设置（如，一个 BW 或者 SAP 配置），那么它们提供的设置将比下面的通用指南有更高的优先级。

• VMO 参数LRU_FILE_REPAGE应该被设成 0 。这个参数是控制是否牺牲计算页或文件系统缓存页。另外，minperm 应该被设为 3 。 这两个参数值是 AIX6.1 里面默认值。
• AIO 参数的 maxservers 默认值可以不再是每个 CPU 10 个。系统一旦激活 maxservers 就调整如下

1. 收集ps – elfk | grep aio的输出并且判断是否所有的异步 I/O（AIO）核心进程（aioservers）消耗同样数量的 CPU 时间。
2. 如果是，maxservers 可能太少了。增加 10% 的 maxservers 然后重复第一步。
3. 如果有些 aioservers 较其它的要使用更少的 CPU 时间，那么至少当前系统拥有它所需要的数目。如果多于 10% 的 aioservers 使用较少的 CPU 时间就降低 10% 的 maxservers 并重复第一步。

• AIO 参数 maxreqs 应该被设置成 MAX（NUM_IOCLEANERS x 256, 4096）. 这个参数控制绝大多数突出的 AIO 请求。
• Hdisk 参数queue_depth应该基于这个队列的物理硬盘数目。例如，对于 IBM 磁盘queue_depth的默认值是 3 并建议这个值是 3 xnumber-of-devices。这个控制参数可排队的磁盘请求。
• 硬盘适配器参数num_cmd_elems应该被设为所有连接到这个适配器的设备 queue_depth 的总和。

Solaris 和 HP-UX 的配置

对于在 Solaris 或 HP-UX 上运行的 DB2，根据系统的大小，利用 db2osconf 工具来检测和推荐内核参数。 db2osconf 允许你基于内存和 CPU 指定核心参数，或与一般缩放系数来比较现有系统配置和未来期望的配置。一个好的方法是使用缩放系数 2 或者更高的缩放系数来运行大型系统如 SAP 应用程序。通常情况下，db2osconf 向你提供了好的起点来配置 Solaris 和 HP-UX，但是由于它无法考虑到现在或者未来的工作负载，它不能带来优化后的值。

Linux 配置

当一个 Linux 系统被用作 DB2 服务器时，可能不得不修改一些 Linux 的一些内核参数。因为 Linux 的发行变化和这个系统的高度灵活性，我们将只讨论一些基于 linux 实施中需要确认的最重要的设置。

SHMMAX（一个共享内存的最大值）在一个 64 位系统必须至少设为 1G － 1073741824，反之 SHMALL 参数必须设置数据库服务器的 90% 可用内存。SHMALL默认值是 8GB 。其它重要的 Linux 内核配置参数以及它们对 DB2 的推荐值是：

• kernel.sem（指定内核旗语的设置 -SEMMSL, SEMMNS, SEMOPM, and SEMMNI）: 250 256000 32
• kernel.msgmni（消息队列的标识数）:1024
• kernel.msgmax（一个消息的最大大小，字节）:65536
• kernel.msgmnb（消息队列的默认大小，字节）:65536

DB2 数据分区特性

使用 DB2 数据分区特性（DPF），通常并不是纯粹由数据容量决定，而更多的是工作负载的性质。大多数 DPF 部署在数据仓库和商业智能上是一个常规的指导方针。对于大型的复杂查询环境 DPF 是被高度推荐的，因为它的 share-nothing 架构提供了优异的可扩展性。对于小一些的不大可能快速增长的数据集市（达到 300GB），一个 DB2 企业服务器版本（ESE）配置是一个很好的选择。然而大型的或快速增长的 BI 环境将从 DPF 中获利。

虽然处理一个完整 DPF 系统设计已经超出了这篇文章的范畴，但是一个 CPU 到分区的基本描述还算简单。一个典型的分区系统通常每个分区拥有一个处理器内核。例如，一个有 N 个处理器内核的系统可能有一个编目分区和 N 个数据分区。如果这个编目分区将被大量使用（例如，拥有单分区维度的表），那么它最好被分配一个处理器内核。如果这个系统将支持许多并发活动用户，就可能每个分区需要两个内核。

作为一个一般性的指南，你应该在每个分区上计划大约 250G 活跃的裸数据。

在 InfoSphere Balanced Warehouse 的文档中有关于 DPF 配置最佳实践的更深入的信息，也包含对于 non-Balanced Warehouse 部署的有用资料。

代码页的选择和校验

除了影响数据库性能的行为之外，代码页或代码集的选择和比较的顺序也许会对性能造成很大的影响。由于 Unicode 允许客户在他们的数据库中比传统单字节代码页呈现更多类型的字符串，使得 Unicode 的使用变得越来越普遍。事实上，它也是 DB2 9.5 的默认值。然而由于 Unicode 代码集使用多字节来呈现一些单独的字符，这将增加磁盘占用和内存需求。如，UTF-8 代码集是一个最常用的 Unicode 代码集，每个字符使用一到四个字节。一个字符串从单字节代码到 UTF-8 代码集在迁移过程中的扩大因素是非常难预测的。因为它取决于多字节字符的使用频率。对于典型的北美内容，通常没有扩大。对于大多数西欧语言，音标字符的使用一般导致 10% 的扩大，但是您的成本会有所不同。

此外，相对于单字节代码页，使用 Unicode 会导致额外的 CPU 开销。首先，如果发生了扩充，越长的字符串处理工作就越久。其次，也更显著的是，该算法采用更先进的 Unicode 整理序列，如 UCA500R1_NO，这比系统整理的典型单字节代码要昂贵得多。而这完全是由于 Unicode 串行排序成文化正确性的方式的复杂性造成的。操作受到了包括排序，字符串比较，like（）处理以及创建索引的影响。

如果正确显示你的数据 Uincode 是必须的，那么请仔细选择校验顺序

• 如果数据库需要存储多语言的数据，并且数据正确的排序顺序非常重要，则应该使用一个文化正确性校验（比如 UCA500R1_xxx）。不过请注意，由于一致性的关系，根据不同的数据和应用程序这将有 1.5x 到 3x 的性能消耗。
• 在文化正确性校验中，有规范化和非规范化的不同。规范化校验（如 UCA500R1_NO）有附加的检查来处理乱码，反之非规范化校验（如 UCA500R1_NX）则不会。除非处理乱码是一个问题，由于避免编码正常化可以带来性能上的好处，我们建议使用非规范化版本。不过，就算是非规范化文化校验也是非常昂贵的。
• 如果一个数据库被从单字节环境迁移到 Unicode 环境，却没有被严格要求支持多种语言（大多数客户属于这个范畴），明确的语言校验或许比较合适。事实上许多 Unicode 数据库值包含一种语言，明确的语言校验（如 SYSTEM_819_BE）将会得到好处。它们使用相同的基于校验运算法则的检查表作为单字节校验，比如 SYSTEM_819，非常有效率。作为一个一般的规则，如果在最初的单字节数据库中的校验行为可以接受，并且语言内容在很长时间内不会改变为 Unicode，明确的文化校验是可以考虑的。这对于文化正确性校验有非常大的性能好处。

数据库的物理设计

详细的数据库物理设计已经在 Sam 的数据库物理设计文章中很好的覆盖了，但是为了达到我们的意图，我们将在这里讨论两个最高阶的最佳实践。

• 通常，数据库管理基于文件存储的普通表空间提供了比系统管理存储普通表空间更好的性能。系统管理表空间经常使用于临时表空间，尤其是临时表非常小的时候。然而数据库管理表空间的性能优势缩短了完成的时间。

• 之前，使用裸设备的数据库管理表空间拥有比使用文件的数据库表空间要好很多的性能优势，但是随着直接 I/O（现在默认通过通过 CREAT 或者 ALTER TABLESPACE 使用 NO FILE SYSTEM CACHING 子句）的引入，使用文件的数据库表空间提供了几乎与使用裸设备的数据库管理表空间相同的性能。

DB2 数据库配置初始设置

数据库配置建议程序，也就是通常所说的 autoconfigure 命令，它根据你提供的系统指南确定一个比较好的数据库配置参数初始值。 Autoconfigure 的确对默认配置的设置有所改进，也是一个用来获得初始配置值的推荐方法。根据不同的系统特性，对 autoconfigure 的推荐值进行一些额外的微调是必要的。

使用 autoconfigure 的建议：

• 虽然从 DB2 9.1 开始会在数据库创建的时候自动运行 autoconfigure，但是直接运行 autoconfigure 仍是一个不错的主意。因为这样我们可以指定关键字 / 值，这有助于在询问中自定义系统的结果。

• 在数据库完成填充后再运行（或重新运行）autoconfig，将向这个工具提供更多关于数据库本身的信息。注意这里的“完成填充”的含义是你将可用的活动数据总量（如，它影响缓冲池大小计算），太多或者太少的数据都将降低计算的精度。

• 尝试 autoconfigure 的重要关键字如 mem_percent,tpm, 以及 num_stmts，判断改变哪些配置值有效，在多大程度上有效。

• 如果你在试验不同的关键字和值时用了” apply none ”选项，这将让你有机会来对推荐值和当前值进行对比。

• 对所有关键字指定具体值，因为默认值可能并不适用与你的系统。例如 mempercent 默认值设置为 25% 这对一个纯 DB2 服务器来说太低了，在这种情况下 85% 是推荐值。

DB2 自调整和自调整参数

DB2 最新版本不论在实例启动还是数据库启动的时候都显著地增加了自动调整或者在操作过程中动态调整参数的数目。除了那些手动精心调试的系统，这对于大多数系统自动设置会带来最好的性能。这主要归功于 DB2 的自调整内存管理器（STMM），它动态调整 DB2 系统中数据库内存总量的分配，如四个主要的内存消费者：缓冲池，lock list，包缓存以及排序堆。

因为那些参数都是基本应用于各个分区的，对于分区环境 STMM 需要注意几点。在分区环境中 STMM 将在一个分区上（DB2 自动选择的，但是可以被废除）持续检查内存需求，判断并把堆大小的更新值推向所有启动了 STMM 的分区。由于所有的分区都使用相同的值，STMM 在各分区的数据总量，内存需求以及综合活动水平都非常统一的 DPF 环境中工作最佳。如果个别分区有数据倾斜或者有不同的内存需求，STMM 则应该在那些分区上停用，而在更一致的分区上启用。例如，STMM 通常应该在编目节点上停用。

对于数据分布发生倾斜的 DPF 环境，不推荐进行跨集群的内存调整，STMM 可以在“调试阶段”有选择临时的使用，以用来帮助确定比较好的手动设置堆大小：

• 在一个有代表性的分区上启动 STMM 。其它分区仍然停止 STMM 。

• 一旦内存设置稳定下来了就停止 STMM 并手动“固化”调整后的值。

• 调整后的值可以部署到其它拥有相近数据量和内存需求的分区上（例如，相同分区组的分区）。

• 如果有多个不同的分区集，每个分区都有相似的数据量与数据类型并在系统中扮演类似的角色，那么就可以反复应用这个流程。

配置顾问工具通常在可应用的用于启用自我管理或自动配置。这包括自动 runstats（非常有用），但是不包括自动重组和自动备份。它们同样非常有用但是为了达到最大的效果需要根据你的环境以及时间表进行配置。自动统计信息应该默认关闭。它有很高耗费并且应该在可控的环境下临时的与复杂语句一起使用。

显式配置设置

某些参数没有自动调整设置，也不能被配置顾问程序调整。这些参数就需要明确的被处理。（注：我们将只考虑与性能相关的那些）

• LOGPATH/NEWLOGPATH 决定事务日志的位置。即使是配置顾问程序也不能判断日志应该放在哪里。如上所说，最重要的一点是它们不能与和其它表空间这样的 DB2 对像共享磁盘驱动，或者就存放在数据库路径下的默认的位置。理想状态下，事务日志应该存放在提供了足够吞吐量的专门存储上以保证不产生瓶颈。

• LOGBUFSZ 决定了事务日志的内部缓存大小（页面大小 4KB）。 8 页的默认值对于良好性能的生产环境来说太小了。根据输入参数，配置顾问程序会一直增加它，但是可能还是不够。这个值通常在 256-1000 页之间是比较好的范围，并且在数据库服务器中会安排一个总量非常小的内存。

• MINICOMMIT 控制’批量提交’，它将令 DB2 尝试把 N 个事务集中批量提交。对于当前事务日志器设计，这只会在非常少的情形下被认为是期望的行为，然而在其它时候我们并不希望这样。 MINCOMMIT 默认设置为 1 。

• BUFFPAGE 决定了每个缓冲池大小定义为 -1 时候分配的页数。最佳实践是忽略 BUFFPAGE 而在 SYSCAT.BUFFERPOLLS 中明确的设置单个缓冲池大小，或让 STMM 自动地调整缓冲池大小。

• DIAGPATH 决定了在各方面都有用的的 DB2 诊断日志文件的存放位置。它通常只对性能有一点影响，在 DPF 环境中可能除外。 DIAGPATH 在分区环境一般是在挂载的共享 NFS 路径。最佳实践是覆盖 DIAGPATH 到每个分区本地非 NFS 路径。这样可以避免所有分区试图更新诊断信息到同一个文件中，作为代替那些文件保持在每个分区本地，并大大减少的争抢。

• DB2_PARALLEL_IO 不是一个配置参数，而是一个 DB2 注册变量。它对于使用有大批硬盘组成的存储的 DB2 而言非常普遍。这个存储对于操作系统而言就是使用一个设备或跨多个设备的文件系统。这样做的结果就是，默认情况下，DB2 对一个表空间容器一次只发出一个预取请求。总之，这个预取以对单个设备多个序列化的请求完成。但是如果容器位于多个磁盘，这就有机会对它同时发送多个预取请求，而不序列化。这就是 DB2_PARALLEL_IO 的由来。它告诉 DB2 预取请求能并行的对单个容器发送。最简单的设置是 DB2_PARALLEL_IO=*（意思是所有容器都存放在多磁盘上，假设在这个例子中是 7），但是其它设置仍然控制并行度以及哪个表空间受影响。例如，如果你知道你的容器在一个 4 块硬盘的 RAID-5 上，你或许会设置 B2_PARALLEL_IO 为“ *:3 ” . 注意精确值对性能是否有好处取决于预取块大小、RAID 段大小以及多少容器使用同一组硬盘。更多存储配置以及 DB2_PARALLEL_IO 的信息，请参考 DB2 数据库存储白皮书中的最佳实践。

统计信息搜集

可以毫不夸张的说拥有正确的统计信息常常是获得 SQL 性能的关键，尤其是在复杂查询的环境中。比起重复在其它文章里面已经写得很好的部分，我们更愿意向读者介绍“写和调优查询语句来优化性能”。

SAP 和其它 ISV 环境需要特别考虑

如果你将 DB2 作为一个 SAP 这样的 ISV 应用程序的数据库服务器来运行，可能需要一些重要的最佳实践来评估特定的应用程序。最直接的方法就是可以把 DB2 注册变量 DB2_WORKLOAD 的值设成‘ SAP ’来启用一批为 SAP 工作负载优化了的注册表变量。

也可以应用其它建议和最佳实践，如选择代码页 / 代码集以及整理序列，它们同样需要预先确定值。更多细节请参考第三方应用程序文档。

像 SAP Business One 这样的许多 ISV 应用程序，autoconfigure 命令可以成功的用于定义初始配置。然而，它不应该在 SAP NetWeaver 安装中被使用，因为在 SAP 安装过程中一个 DB2 配置的初始设置已经被应用了。另外，SAP 有一个强大的可供选择的最佳实践步骤。根据 SAP Note 它记录了首选的 DB2 参数设置。例如 SAP Note1086130-DB6:DB2 9.5 标准参数设定。

要特别注意的是，SAP 应用程序使用 DB2 DPF 功能是需要付费的。 SAP 主要在它们 NetWeaver Business Intelligence（Business Warehouse）中使用 DPF 。建议的布局是把 DB2 系统编目、维度和 master 表加上 SAP 的基础表放在 0 号分区。这这样布局是由于这个分区的工作负载不同于其它分区。因为 SAP 应用程序服务器运行在这个分区，仅这个分区可以分配多达 8 个处理器，而且 SAP BW 工作负载变得并行度越来越高，许多简短的 SQL 语句并行运行，分区的数据将通常少于其它的应用程序。换句话说，每个分区将需要不止一个 CPU 。

要获取更多关于 DB2 和 SAP 初始安装的细节，请参考 SAP Service Marketplace（service.sap.com）或者SAP Developer Network

第二步：监控系统性能

在设定一个初始系统配置后，实施一个监控策略就变得非常重要。这将使你能随着时间的流逝对许多重要的系统性能度量监视元素进行跟踪。这在给你的关键数据初始配置带来改进值以更好适应你的需求的同时，它也同样可能会在软件升级、数据量或者用户人数增加、或者新应用程序开发等方面给你带来新的问题。

我们拥有数百种度量监视元素以供选择，但是由于产生数据的总量，收集所有数据会产生相反的作用。我们所希望的尺度是：

• 易于搜集－我们不希望日常监控中使用复杂或昂贵的工具，也不希望监控操作明显地成为系统的负担。

• 易于理解－我们不希望在看到这个度量监视元素的同时还需要去查询它的含义。

• 和系统相关－并不是所有的度量监视元素在所有系统上都有意义。

• 灵敏而不敏感 －所有度量监视元素的改变应该反应了真实的系统的改变、或稳定。度量不应该自己发生变动。

DB2 有很多的监视元素，我们将选择符合需求的那些。就像人的身体，心率是一个很好的但不是最好的度量监视元素，因为它是基于很多因素的变化度很高－它太敏感了。心率的变化并不代表我们的”系统”有了问题。然而，身体的温度是一个很好的度量，因为它非常的稳定，却对很多我们可能关注的问题非常敏感。

区分操作监控（那些我们日常做的基础的事情）和异常监控（我们搜集额外数据来帮助诊断问题）的主要的差别是操作监控只需要轻量级（它的测量并不消耗太多的系统资源）和一般的资源 - 留意任何可能出现在系统中的潜在问题。在这个部分，我们将主要专注于操作监控。

DB2 提供了一些极好的资源来监控数据，最主要的是快照监控器和在 DB2 9.5 以及以后版本中的工作负载监控管理（WLM）汇总功能。它们都专注于概要数据、计数器、计时器、柱状图、等等… ，来维护系统中所有运行活动。随着时间的推移，通过取样我们能得出在这期间的平均活动情况，这会产生非常丰富的信息。

和照相类似，快照和汇总统计信息向我们提供了一张单独的系统活动画面。在某些情况下它是如同闪光摄影一样是即时的，但是更多的情况下它是‘定时曝光’的，显示了在相当长时间内发生的事情。 DB2 同样提供了‘动画’监控，它记录了一系列单独的活动。这由跟踪这类的机制完成，比如事件监控器（尤其是语句事件监控器）WLM 活动监视器，它们是紧密相关的。比起我们从快照的得到的摘要，它们提供了对系统活动更多更全面的细节记录。然而，跟踪会产生大量的数据并对系统产生非常大的影响。因此它们比起操作监控来，更适用于异常监控。

没有任何理由限制我们只能使用 DB2 提供的度量监视元素。事实上，非 DB2 数据比起作为一个好的背景资料，更多的是判断性能问题的关键。用户，应用程序，操作系统，存储系统，网络，所有这些可一个提供对系统性能有价值的信息。在 DB2 之外的度量监控元素是生成一个完整的系统性能全景图像的非常重要的一部分。

由于我们打算在整个系统生命周期内对操作的度量监视元素正常的搜集信息，拥有一种可以管理所有数据的方法非常重要。对于我们将有的对数据可能的用途，比如长期的性能倾向（例如，我们想比较的任意两个数据集合可能相隔数月）。 DB2 本身非常适合对这种数据进行管理。分析和比较数据也变得非常简单；对于长期的数据存储和组织，我们也已经有了一个强大的基础架构。

DB2 8.x 和 9.x 的趋势是通过 SQL 接口会产生越来越多的监控数据 。由于我们可以简单的重定向管理视图数据，这使 DB2 监控数据的管理非常简单，比如，回到 DB2 表。更深入的，事件监控和活动监控数据也能写入 DB2 表提供类似的好处。由于绝大多数监控数据可以如此简单的存进 DB2，对 DB2 存储系统度量监视元素（如来自于 vmstat 的 CPU 利用率）进行小的投资也是很容易控制的。

DB2 快照度量监视元素的一个很好的‘起始设置’

这些来自于数据库快照度量监视元素（db2 get snapshot for database ondbname）。如上面所提到的，为了分析和便于长期管理，最佳实践就是通过相应的管理视图（db2 select … from sysibmadm.snapdb）来访问那些元素。注意，为了 snapshot 表函数和管理视图可以访问数据，实例级的监控器开关需要打开。例如，开启 DFT_MON_BUFPOOL 是为了收集缓冲池的监控数据。幸运的是它们都属于动态开关而且开启或关闭它们不必重启实例。在下面的例子中，我们将强调管理视图中用来判断每一个度量监视元素的列。

关于 DPF 的注释：如果你正在运行一个多分区环境，你需要在监控的查询语句中包含 DBPARTITIONNUM，以区分各个分区的返回记录。

1. 通过COMMIT_SQL_STMTS，SELECT_SQL_STMTS和UID_SQL_STMTS，得到执行 SELECT 语句和 INSERT/UPDATE/DELETE 语句的事务的数目。

1. 通过下面公式

1 2 3 4 5 6 7 8 9

100% * (POOL_DATA_L_READS – POOL_DATA_P_READS)  / POOL_DATA_L_READS    100% * (POOL_INDEX_L_READS – POOL_INDEX_P_READS)  / POOL_INDEX_L_READS    100% * (POOL_TEMP_DATA_L_READS - POOL_TEMP_DATA_P_READS) / POOL_TEMP_DATA_L_READS    100% * (POOL_TEMP_INDEX_L_READS - POOL_TEMP_INDEX_P_READS) / POOL_TEMP_INDEX_L_READS

得到缓冲池命中率，分别对于数据，索引，和临时数据的测量结果。

缓冲池命中率是一个最基础的度量监视元素，对让系统如何有效利用内来存避免磁盘 I/O，提供了一个重要并全面的方法。 80-85% 或更高的数据命中率， 90-95% 或更高的索引命中率通常被认为对一个 OLTP 环境很好，当然可以通过计算缓冲池快照的数据得到对单独的缓冲池的命中率。

虽然那些度量监视元素通常都很有用，不过对于像数据仓库这样经常允许大表查询的系统，数据命中率经常会低得不可救药。因为数据是首先读到缓冲池然后在为其它数据腾空间被回收之前不再使用。

3. 通过

1 2 3 4 5 6

(POOL_DATA_P_READS+ POOL_INDEX_P_READS +  POOL_TEMP_DATA_P_READS + POOL_TEMP_INDEX_P_READS)  / COMMIT_SQL_STMTS    (POOL_DATA_WRITES + POOL_INDEX_WRITES)  / COMMIT_SQL_STMTS

得到每个事务的缓冲池物理读写。

这些度量监视元素和缓冲池的命中率都非常相似，但是目的略有不同。我们可以谈论命中率的目标值，不过每个事务的读写目标值没有相似的可能。为什么我们要被这些计算而困扰呢？因为磁盘 I/O 是数据库性能的一个主要因素，用多个角度对它进行观察是有好处的。同样的，那些计算包也括了写入操作，否则命中率只与读取有关。最后，如果孤立地看，它非常难以判断。例如，是否一个 94% 索引命中率值得去提高。如果每小时仅进行 100 次逻辑读，并且其中 94 次在缓冲池中，去保持最后的 6 次把它们变成逻辑读不是浪费时间。然而，如果 94% 的索引命中率是对每个事务执行了 20 次物理读（可以进一步被划分成数据，索引，常规，临时）统计得来，缓冲池命中率很可能值得进行一些研究。

这里要注意，度量监视元素并不只有物理读写，不过对于每个事务都规格化了。我们通过许多度量监视元素遵循了这一趋势。目的就是把对度量监视元素的数据收集从持续时间和系统繁忙程度上分离开来。通常这会得到保证，我们将的到相似的度量监视元素的值，而不管我们是否非常精确的知道数据怎样以及何时收集。当然在数据搜集过程中的时间连贯性是很好的事情，然而标准化将这种需求从“关键”减到“很好”。

4. 通过 ROWS_READ / ROWS_SELECTED 来计算数据库在行查询的行读取命中率。这给我们的计算表明了为了找到匹配的行从数据库表读取的平均行数。数字越低表明查找数据越有效，并且通常表明使用索引会更有效。例如，系统作了很多表查询而且需要扫描上百万行的数据以判断是否符合结果集的要求，在这种情况下这个数字就会非常的高。另一方面，对表的访问是通过完全匹配的唯一索引实现的，在这种情况下这个统计结果就非常的低。注意，那种只访问索引的查询计划（不需从表读取行）不会增加 ROWS_READ 。

在一个 OLTP 环境中，这个度量监视元素的结果不高于 2 或 3，就表明大多数访问都是通过索引而非表扫描。这个度量监视元素是一个简单的方法来监控访问计划在一段时间内的稳定性。

5. 要计算每个事务花在排序上的总时间。这是一个处理排序统计信息的有效途径，因为任何额外的开销都是由于被自动包括在内的溢出排序造成的。也就是说，你可能也想收集 TOTAL_SORTS 和 SORT_OVERFLOWS 来简化分析，尤其是你的系统过去发生过排序问题。

6. 通过

1	1000 * LOCK_WAIT_TIME / COMMIT_SQL_STMTS

来计算每 1000 个事务锁等待的总时间。

过多的锁等待时间经造成成较差的反馈时间，所以监控非常重要。注意我们标准化 1000 笔事务是因单个事务的锁等待时间一向很低。放大到 1000 笔事务给我们一个更容易把握的简单衡量。

7. 通过

1	1000 * （DEADLOCKS + LOCK_TIMEOUTS） / COMMIT_SQL_STMTS

计算每千笔事务发生的死锁和锁超时数目。

虽然死锁在大多数生产系统中比较少，锁超时却很经常。应用程序通常不得不以相似的方法处理它们 - 重头开始运行这个事务。监控这种较少发生的情况有助于在 DBA 还没有注意到时就避免许多死锁 / 锁超时在系统上造成明显的额外负载。

8. 通过

1	1000*POOL_DRTY_PG_STEAL_CLNS/COMMIT_SQL_STMTS

计算每千笔事务中触发的‘ dirty steal ’操作。

一个‘ dirty steal ’是触发缓冲池页清除的最差方法。本质上，SQL 语句的处理需要新的缓冲池页面操作是不连续的，当更新发生在牺牲页面则将写入磁盘。如果 dirty steal 被允许频繁发生，它们将对吞吐量和反映时间产生明显的影响。因此，它们在我们需要提防的列表中。

9. 通过

1	1000*PKG_CACHE_INSERTS/COMMIT_SQL_STMTS

计算每千笔事务的包缓存插入。包缓存插入是系统正常执行的一部分；然而，如果数目过大这将明显的消耗 CPU 时间。在很多良好设计的系统中，一旦系统处于稳定运行状态，只会发生很少的包缓冲插入。因为系统是使用 / 重用静态 SQL 或先前准备好了的动态 SQL 语句。 SQL 编辑和包缓存插入不能避免。然而，这个度量监视元素专门监视第三种状态－应用程序无意识造成的不可重用的准备语句或者经常使用的 SQL 语句中的不重用参数标记搅动包缓存。

10. 通过

1 2	LOG_WRITES/COMMIT_SQL_STMTS（LOG_WRITE_TIME_S + LOG_WRITE_TIME_NS / 1000000.0）  /COMMIT_SQL_STMTS

计算每个事务的活动日志数。

事务日志很有可能成为系统瓶颈，无论是因为高度活跃，或者不正确的配置，或是其它什么原因。通过监控日志活跃程度 - 日志写的次数和写的时间 - 我们能发现问题，不管是 DB2 这边的（也就是，应用程序发起的日志请求增加）还是操作系统那边的（经常由于硬件或者配置问题导致的日志文件系统性能降低）。

11. 通过

1 2	sysibmadm.snapfcm_part.TOTAL_BUFFERS_SENT  sysibmadm.snapfcm_part.TOTAL_BUFFERS_RCVD

来计算在 DPF 上，分区间的快速通信管理器发送和接收缓冲请求块的数目。这些结果给出了集群中不同分区间的数据流的速度，通常的也可以得出数据是否平衡。从不同分区接收到的缓冲请求块的数目如果明显不同，这可能预示哈希分布到每个分区的数据总量发生了倾斜。

12. 注意，查询 sysibmadm.snapfcm_part 提供了所有系统分区对的流信息－不仅是发送也包括了当前节点的接收，这也是 GET SNAPSHOT FOR FCM 得到的。像下面列子为 DBPARTITIONNUM 添加一个谓词来返回当前节点的数据。

1 2 3

select DBPARTITIONNUM, FCM_DBPARTITIONNUM, TOTAL_BUFFERS_SENT, TOTAL_BUFFERS_RCVD  from sysibmadm.snapfcm_part  where DBPARTITIONNUM = current DBPARTITIONNUM

收集其它重要的数据

如上面提到的，虽然 DB2 监视元素提供了大量的关键运行数据， 增加其它类型的数据收集同样重要。首先，我们需要 DB2 在一个正常基础上抓取它自己的配置信息。获得数据库和数据库管理器配置的正常的备份，DB2 注册变量和模式定义帮助提供我们所有更改的历史记录，并有助于解释监控数据变化的原因。

其次，监控整个系统负载同样非常重要。如果 CPU 或者 I/O 的使用达到饱和，这将造成系统瓶颈，仅用 DB2 快照来探测可能会比较困难。所以，最佳实践就是，在基于 UNIX 的系统上正常地使用 vmstat 和 iostat（对网络问题使用 netstat） 或者 windows 上的 perfmon 来监控系统负载。一般情况下，比起精确的匹配通用值，你将更多的去寻找什么样的改变对于你系统正常的。

最后同样重要的是，在商业逻辑层面，从基于 DB2 的吞吐量和反映时间标准的意义上来说，抓取应用程序的性能视图也非常重要。它有和终端用户直接相关的好处，以及它通常包含了所有可以造成瓶颈的因素，比如演示逻辑、应用服务器、Web 服务器、多层网络、等等。 这数据在设置或者验证一个服务层协议的过程中可以非常重要。

以上度量监视元素显示了在一个正在进行基础上的核心数据集。虽然快照每五到十五分钟收集一次，监视元素和系统负载数据依然结合的很紧密。在大多数系统中数据总量与时间的推移毫无关系。同样的，通常搜集这些数据将增加 1% 到 3% 的额外 CPU 开销，对于收集这些重要的系统度量监视元素相关数据来说，这是很小的代价了。因为配置信息一般很少变动，所以一天搜集一次通常就足够了，这样做在不产生多余数据的情况下这是有好处的。

根据你的系统环境情况，你或许会发现对那些核心度量监视元素之外收集附加信息是有好处的。

• 各个缓冲池数据让我们有机会对每一个缓冲池的命中率和物理 I/O 分开来看（从 sysibmadm.snapbp 管理视图获得）。

• 动态 SQL 数据向我们提供了每个语句在系统中执行的信息。包括缓冲池活动明细，花费的时间和 CPU 消耗（从 sysibmadm.snapdyn_sql 管理视图获得）

• 应用程序的状态数据（从 sysibmadm.snapappl 和 sysibmadm.snapappl_info 管理视图获得 ）让我们获得了与上面核心数据库管理视图（sysibmadm.snapdb）类似的信息，不过是针对每个应用程序的。这为向下钻取的需求提供了非常有用的附加信息，能帮助我们了解性能问题可能是哪个应用程序导致的。

如果我们打算向下钻取并挖掘出额外的监控信息，比起提前预料哪些域可能有需求并只收集那些信息而言，最简单的就是搜集所有管理视图中我们感兴趣的元素。

在 DPF 环境中跨分区监控

基本上前面提到的所有单独的监控元素都是基于一个单分区环境提出来的。同样的我们搜集的大量非 DB2 性能数据，如 vmstat 和 iostat，也都是针对单个操作系统实例的统计信息（虽然或许跨了多个逻辑分区）。这对匹配我们用来控制系统的 DB2 配置参数有监控粒度的意识是有好处的。然而在 DPF 中我们同样必须能监控分区间的活动，比如为了能发现分区间的数据量不平衡，等等。

幸运的是，我们从管理视图中收集的 DB2 监控信息包括了一个 DBPARTITIONNUM 列值既能帮助我们根据分区号码查询监控信息，又能对分区间进行比较。

一般情况下，我们期望在同一个分区组中的所有分区的监控统计信息能相对一致。明显的不同可能意味着数据倾斜。我们需要跟踪的分区间的比较信息的例子包括：

• 数据、索引和临时表的逻辑和物理缓冲池读写

• 大型表在分区间的行读取

• 排序时间和排序溢出

• FCM 缓冲块的发送和接收

• CPU 和 I/O 利用

如果通过这些度量监视元素我们发现任何数据分区看起来比同一分区组中最不活跃的数据分区明显更加活跃（例如，忙碌 10-20%），尤其是如果这个比较忙碌的分区 CPU 或者 I/O 出现饱和，那么这个数据分区很可能需要检查数据倾斜，找出每个大的多分区的表哈希分布到各个分区的行数将验证数据倾斜是否存在。

1	select count（*）,dbpartitionnum（P_PARTKEY）from tpcd.partgroup by dbpartitionnum（P_PARTKEY）

DB2 白皮书‘物理数据库设计最佳实践’讨论了如何使用 DB2 Design Advisor 来在你系统中选择正确的分区键，以避免数据倾斜同样最小化 non-collocated 连接。

1	select count（*）,dbpartitionnum（P_PARTKEY）from tpcd.partgroup by dbpartitionnum（P_PARTKEY）

第二部分我们将介绍问题诊断。