DB2 最佳实践-性能调优和问题诊断最佳实践
DB2 最佳实践: 性能调优和问题诊断最佳实践，第1 部分
性能调优从配置和监控开始
2009 年 3 月12 日
本系列介绍了DB2 系统性能的最优方法，分两部分。第一部分首先介绍为了达到良好性能，我们如何从软硬件配置方面来保障，紧接着讨论了在多种在操作和故障诊断的情况下，有助于我们了解系统性能的监控方法。第 2 部分我们介绍在出现性能问题时如何逐步地、有条不紊地去处理它们。
内容提要
大多数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 个底层驱动，配置的吞吐量将受到非常严重的降低。参见
更多信息请参见存储配置最佳实践。
为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 x number-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
（https://www.wendangku.net/doc/eb12117954.html,）或者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 on dbname）。如上面所提到的，为了分析和便于长期管理，最佳实践就是通过相应的管理视图（db2 sel ect … from sysibmadm.snapdb）来访问那些元素。注意，为了snapshot 表函数和管理视图可以访问数据，实例级的监控器开关需要打开。例如，开启DFT_MON_BUFPOOL 是为了收集缓冲池的监控数据。幸运的是
它们都属于动态开关而且开启或关闭它们不必重启实例。在下面的例子中，我们将强调管理视图中用来判断每一个度量监视元素的列。
关于DPF 的注释：如果你正在运行一个多分区环境，你需要在监控的查询语句中包含DBPARTITIONNUM，以区分各个分区的返回记录。
1. 通过COMMIT_SQL_STMTS，SELECT_SQL_STMTS和UID_SQL_STMTS，得到执行SELECT 语句和INSERT/UPDATE/DELETE 语句的事务的数目。
1.通过下面公式
得到缓冲池命中率，分别对于数据，索引，和临时数据的测量结果。
缓冲池命中率是一个最基础的度量监视元素，对让系统如何有效利用内来存避免磁盘I/O，提供了一个重要并全面的方法。80-85% 或更高的数据命中率，90-95% 或更高的索引命中率通常被认为对一个OLTP 环境很好，当然可以通过计算缓冲池快照的数据得到对单独的缓冲池的命中率。
虽然那些度量监视元素通常都很有用，不过对于像数据仓库这样经常允许大表查询的系统，数据命中率经常会低得不可救药。因为数据是首先读到缓冲池然后在为其它数据腾空间被回收之前不再使用。
3. 通过
得到每个事务的缓冲池物理读写。
这些度量监视元素和缓冲池的命中率都非常相似，但是目的略有不同。我们可以谈论命中率的目标值，不过每个事务的读写目标值没有相似的可能。为什么我们要被这些计算而困扰呢？因为磁盘I/O 是数据库性能的一个主要因素，用多个角度对它进行观察是有好处的。同样的，那些计算包也括了写入操作，否则命中率只与读取有关。最后，如果孤立地看，它非常难以判断。例如，是否一个 94% 索引命中率值得去提高。如果每小时仅进行100 次逻辑读，并且其中94 次在缓冲池中，去保持最后的 6 次把它们变成
逻辑读不是浪费时间。然而，如果94% 的索引命中率是对每个事务执行了20 次物理读（可以进一步被划分成数据，索引，常规，临时）统计得来，缓冲池命中率很可能值得进行一些研究。
这里要注意，度量监视元素并不只有物理读写，不过对于每个事务都规格化了。我们通过许多度量监视元素遵循了这一趋势。目的就是把对度量监视元素的数据收集从持续时间和系统繁忙程度上分离开来。通常这会得到保证，我们将的到相似的度量监视元素的值，而不管我们是否非常精确的知道数据怎样以及何时收集。当然在数据搜集过程中的时间连贯性是很好的事情，然而标准化将这种需求从“关键”减到“很好”。
4. 通过ROWS_READ / ROWS_SELECTED 来计算数据库在行查询的行读取命中率。这给我们的计算表明了为了找到匹配的行从数据库表读取的平均行数。数字越低表明查找数据越有效，并且通常表明使用索引会更有效。例如，系统作了很多表查询而且需要扫描上百万行的数据以判断是否符合结果集的要求，在这种情况下这个数字就会非常的高。另一方面，对表的访问是通过完全匹配的唯一索引实现的，在这种情况下这个统计结果就非常的低。注意，那种只访问索引的查询计划（不需从表读取行）不会增加ROWS_READ 。
在一个OLTP 环境中，这个度量监视元素的结果不高于 2 或3，就表明大多数访问都是通过索引而非表扫描。这个度量监视元素是一个简单的方法来监控访问计划在一段时间内的稳定性。
5. 要计算每个事务花在排序上的总时间。这是一个处理排序统计信息的有效途径，因为任何额外的开销都是由于被自动包括在内的溢出排序造成的。也就是说，你可能也想收集TOTAL_SORTS 和
SORT_OVERFLOWS 来简化分析，尤其是你的系统过去发生过排序问题。
6. 通过
来计算每1000 个事务锁等待的总时间。
过多的锁等待时间经造成成较差的反馈时间，所以监控非常重要。注意我们标准化1000 笔事务是因单个事务的锁等待时间一向很低。放大到1000 笔事务给我们一个更容易把握的简单衡量。
7. 通过
计算每千笔事务发生的死锁和锁超时数目。
虽然死锁在大多数生产系统中比较少，锁超时却很经常。应用程序通常不得不以相似的方法处理它们- 重头开始运行这个事务。监控这种较少发生的情况有助于在DBA 还没有注意到时就避免许多死锁/ 锁超时在系统上造成明显的额外负载。
8. 通过
计算每千笔事务中触发的… dirty steal ?操作。
一个… dirty steal ?是触发缓冲池页清除的最差方法。本质上，SQL 语句的处理需要新的缓冲池页面操作是不连续的，当更新发生在牺牲页面则将写入磁盘。如果dirty steal 被允许频繁发生，它们将对吞吐量和反映时间产生明显的影响。因此，它们在我们需要提防的列表中。
9. 通过
计算每千笔事务的包缓存插入。包缓存插入是系统正常执行的一部分；然而，如果数目过大这将明显的消耗CPU 时间。在很多良好设计的系统中，一旦系统处于稳定运行状态，只会发生很少的包缓冲插入。因为系统是使用/ 重用静态SQL 或先前准备好了的动态SQL 语句。SQL 编辑和包缓存插入不能避免。然而，这个度量监视元素专门监视第三种状态－应用程序无意识造成的不可重用的准备语句或者经常使用的SQL 语句中的不重用参数标记搅动包缓存。
10. 通过
计算每个事务的活动日志数。
事务日志很有可能成为系统瓶颈，无论是因为高度活跃，或者不正确的配置，或是其它什么原因。通过监控日志活跃程度- 日志写的次数和写的时间- 我们能发现问题，不管是DB2 这边的（也就是，应用程序发起的日志请求增加）还是操作系统那边的（经常由于硬件或者配置问题导致的日志文件系统性能降低）。
11. 通过
来计算在DPF 上，分区间的快速通信管理器发送和接收缓冲请求块的数目。这些结果给出了集群中不同分区间的数据流的速度，通常的也可以得出数据是否平衡。从不同分区接收到的缓冲请求块的数目如果明显不同，这可能预示哈希分布到每个分区的数据总量发生了倾斜。
12. 注意，查询sysibmadm.snapfcm_part 提供了所有系统分区对的流信息－不仅是发送也包括了当前节点的接收，这也是GET SNAPSHOT FOR FCM 得到的。像下面列子为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 出现饱和，那么这个数据
分区很可能需要检查数据倾斜，找出每个大的多分区的表哈希分布到各个分区的行数将验证数据倾斜是否存在。
DB2 白皮书…物理数据库设计最佳实践?讨论了如何使用DB2 Design Advisor 来在你系统中选择正确的分区键，以避免数据倾斜同样最小化non-collocated 连接。
第二部分我们将介绍问题诊断。
本系列介绍了DB2 系统性能的最优方法，分两部分。第 1 部分首先介绍为了达到良好性能，我们如何从软硬件配置方面来保障，紧接着讨论了在多种在操作和故障诊断的情况下，有助于我们了解系统性能的监控方法。第 2 部分我们介绍在出现性能问题时如何逐步地、有条不紊地去处理它们。
概述
就算是配置最仔细的系统也终究会发现它仍然需要一定的性能调优，并且这时我们已经搜集了的运行监控数据，将来非常便于搜集。
保持一种系统的方法来调优和进行故障诊断对我们非常重要。当发生了一个问题，为了解决这个问题，很容易随意的进行调整。然而，当我们这么做了，事实上定位到问题的可能性非常低，甚至让问题更糟糕。性能调优的一些基本原则：
1.有备而来，去了解系统一切正常的情况下性能怎么样。搜集运行监视信息来跟踪一段时间内系统
行为的变化。
2.了解整个场景，不要局限于你从DB2 上看到的–也要搜集并分析来自于操作系统、存储、应
用程序甚至来自用户的数据。了解系统本身将有助于你解释监控数据。
3.只调整能解释你看到的症状的参数，如果连发动机都无法启动就不要更换轮胎。不要试图通过降
低CPU 来解决磁盘的瓶颈。
4.一次只改一个参数，在更改其它参数之前先观察效果。
你可能遇到的问题类型
性能问题往往分为两大类：影响了整个系统的问题和只影响了部分系统的问题。比如某一特定应用或SQL 语句，在研究的过程中－种类型的问题可能转化为另外一种类型的问题，或者相反。例如造成整个系统性能降低可能是一个单独的语句，或者是整个系统的问题只是在一个特定的区域被发现。
下面我们从整个系统的问题开始。
我们发现的所有导致性能降低的原因的方法就是从高层入手并逐渐提炼我们的诊断。这个“判断树”策略可以帮助我们尽可能早的排除那些不能解释我们所看到症状的因素，适用于整个系统或者更加局部的问题。我们将把瓶颈分成下面 4 种普通类型：
1.磁盘
2.CPU
3.内存
4.…懒惰系统?
在开始一个对DB2 调查之前，首先考虑一些准备问题常常是有帮助的，比如：
1.是否有性能降低，与什么相关？我们的…基准?是什么？
2.一个系统的性能看起来在随时间流逝下降了？与一个不同的系统或不同的应用比较下降了？这个
问题可以对性能降低的原因展开不同的可能性。数据量增加了？所有的硬件都运行正常吗？
3.性能下降是什么时候发生的？在另一个任务运行之前、之中、之后，性能下降或许周会期性的发
生。甚至如果这个任务没有直接和数据库相关，它也可能由于消耗网络或者CPU 资源影响数据库性能。
4.性能下降的前后关系有什么变化吗？通常是，添加了新硬件、或应用程序被更改了、大量数据被
加载、或者更多的用户访问这个系统。
5.在据库专家和应用程序以及架构方面的专家一起工作的情况下，这些问题通常是一个综合分析方
法一个很重要的部分。DB2 服务器几乎总是硬件、其它中间件、和应用程序这样一个复杂环境的一部分，所以解决问题可能需要有多领域的技能。
回页首磁盘瓶颈
磁盘瓶颈的基本症状是：
?在vmstat 或iostat 结果中出现较高的I/O 等待时间。这显示系统会花费一小段时间等待磁盘I/O 完成请求。等待时间达到20% 或25% 是很少见的。如果CPU 时间非常低，那么高I/O 等待时间是一个很好的预示了瓶颈所在。
?从iostat 或 perfmon 显示磁盘高达80% 的繁忙程度。
?从vmstat 输出中看到较低的 CPU 利用率（25%-50%）
可能最终我们可能需要添加磁盘，但现在我们将检查我们是否能通过调优DB2 系统消除这个瓶颈。
如果存在一个磁盘瓶颈，系统管理员可以帮忙映射一个繁忙设备镜像的文件系统路径。从这里你可以决定DB2 如何使用这些受到影响的路径:
?瓶颈是表空间容器？这取决于在sysibmadm.snapcontainer 中查询
TBSP_NAME,TBSP_ID 和CONTAINER_NAME 的结果，查看造成瓶颈的路径是否在
CONTAINER_NAME 结果中。
?瓶颈是事务日志路径？这取决于检查数据库配置参数的结果，查看造成瓶颈的路径是否是“日志文件路径”。
?作为诊断日志路径？这取决于检查数据库管理配置参数的结果，查看造成瓶颈的路径是否是DIAG_PATH 。
我们将分别考虑这几种情况。
为了判断是什么导致容器成为瓶颈的，我们需要判断都有哪些表存储在这那个表空间而且最活跃。
1.要判断什么表在这个表空间，需要查询syscat.tables，把TBSPACEID 同上面的
snapcontainer.TBSP_ID 匹配
2.要找出哪些表最活跃，需要查询sysibmadm.snaptab，选择在我们繁忙的容器上的表的
ROW_READ 和ROW_WRITTEN 。查看那些水平活跃程度比其它要高很多的表。注意这需要打开实例级表监控开关DFT_MON_TABLE
进一步向下钻取，我们需要找出什么造成了这个表的高水平的活跃程度。是动态SQL 语句造成的高度活跃？通过sysibmadm.snapdyn_sql.TBSP_ID 查询动态SQL 快照，来找出我们感兴趣的那些涉及这个表的语句：
列返回能包含行的读和写，缓冲池活跃程度，执行时间，CPU 时间，等等。我们能在列上使用ORDER BY 子句，比如ROWS_READ,ROWS_WRITTEN 和NUM_EXECUTIONS 来集中那些对表有最大影响的语句。注意我们假设这里的表名在SQL 语句的头32672 个字符中。这个假设虽然不完美，却在大多数情况下正确，也是需要使用LIKE 。
是否是静态SQL 语句导致的高活跃程度？在这里我们需要使用系统编目表和db2pd 来找出哪写语句
最活跃。查询syscat.statements, 参考那些我们关注的表：
一旦我们有了涉及到我们感兴趣的那些表的静态SQL 语句的包名和片段数字，我们就可以使用db2pd –static 来找出它们中哪些是高度活跃的。Db2pd – static 的输出都有一条从实例启动并执行过的每一个静态SQL 语句的记录。NumRef 计数器这条语句已经运行了多少次，并且RefCount 计数器显示了当前有多少DB2 代理程序正在运行这条语句。监视db2pd –static 结果中的每一条调用记录。NumRef 值的迅速攀升、RefCount 的值经常超过 2 或3，往往表明这是一个高度活跃的语句：
如果我们能确定并得出一个或多个SQL 语句导致了I/O 瓶颈，下一步我们需要确这个语句是否可以被优化以降低I/O 。这个语句是否发起了一个不期望的表扫描？这可以通过用db2exfmt 检查查询计划以及比较这个问题语句的ROWS_READ 和ROW_SELECTED 来验证。由于在表扫描中使用了过时的统计信息或有索引问题，经常在临时查询的时候不可避免会发生表扫描，但是一个导致过多I/O 并造成瓶颈的重复查询还是应该被讨论的。另一方面，如果受到的影响的表非常小，那么增加缓冲池大小对减少I/O 和消除瓶颈或许已经足够了。详情参考这里对于查询优化和物理设计的最佳实践文章。
在我们讨论索引容器之前，先介绍两个数据容器磁盘瓶颈的情况：
1.我们希望一个产生大量磁盘读取的表扫描通过预取器完成。如果在预取过程中有任何问题（见下
面的懒惰系统），读入缓冲池操作都将被代理程序自己完成，并且－每次只读取一页。在这种情况下，会产生导产生大量闲置的“懒惰系统”，或（如我们在此讨论的）磁盘瓶颈。因此如果有磁盘瓶颈是由于表扫描造成的，但是在iostat 中却显示的读入大小比那个表空间的预取大小要小很多的话，可能是预取不足导致的问题。
2.通常，为了保证表空间后续读取时候有足够的可用缓冲池页面，页清理会对这个表空间产生一个
稳定的写出流。然而如果在调整页清除有问题（见懒惰系统的瓶颈），代理程序将停下来自己做清理。这常常会产生页面清理的…爆发? - 周期性的高度活跃的写入（可能造成磁盘瓶颈），并与
良好性能交替出现。
在后面懒惰系统的瓶颈章节，有更多关于如何诊断和解决这两个问题信息。
一个发生在容器中的瓶颈，更多的可能是表活跃而不是索引活跃，但是一旦我们排除了表活跃的原因，我们就应该调查是否是索引活跃造成的问题。应为我们没有索引快照可以一用，就不得不通过间接的发现问题。
1.在表空间中索引读写是否很活跃？对表空间查询sysibm adm.snaptbsp 的TBSP_ID 对应上
面snapcontainer 的TBSP_ID.
2.
3.一个很大并不断增长的POOL_INDEX_P_READS 或POOL_INDEX_WRITES 值表明这个
表空间有一个或多个…忙碌的索引?。
4.这个表空间中有什么索引？
查询syscat.tables 和上面的snapcontainer.TBSP_NAME 匹配INDEX_TBSPACE 。
5.这其中哪些索引是高度活跃的？如果在我们检查的表空间上有不止一个索引，我们就需要查看索
引层面的活跃程度。反复搜集db2pd – tcbstats index – db
索引扫描通常很划算，所以基于这一点研究是否能在缓冲池中放入更多的索引而非直接从硬盘读取是很合理的。增加缓冲池的大小，或为索引指定专门的缓冲池，可能足以降低I/O 来消除平均。注意，在数据仓库环境中的索引通常非常大，分配足够的缓冲池来消除I/O 不大可能。在那种情况下，通过增加额外的容器以提高磁盘I/O 带宽来消除瓶颈或许更加有效。
在我们找到了一个… hot table ?后，如果我们不能通过调优消除索引I/O 瓶颈，或许我们需要更进一步的向下钻取，以找到导致索引I/O 的SQL 语句。不幸的是，我们并不能再一次像之前我们所做的那样只挖掘SQL 语句文本，至少I/O 瓶颈和具体的索引没有直接连系。
利用索引名称确定相应的表，然后用表名和上面描述的方法从活跃的表上找到可能使用这些索引的动态或静态的SQL 语句。（这并不保证和表相关就一定会被使用。）那么我们需要使用db2exfmt 来确定是否这些语句使用了索引。
从另一方面，如果这个繁忙的容器属于一个临时表空间，那么我们就需要考虑两个可能的原因。
1.是否这个临时表空间的I/O 繁忙是由于排序溢出？这是一种情况，排序从设计的内存缓冲溢出
必须使用一个临时表空间来代替。如果排序时间和溢出快照监控元素很高而且不断增长，或许这
就是原因。
2.
3.STMM 会尽全力避免这种情况；然而如果你没有使用STMM 来控制sheapthres_shr 和
sortheap，你可能需要手动来增加这些值。
4.是I/O 由于庞大的中间结果导致的吗？如果是，这表明通过大量的临时数据的物理读写。我们
应该在最初的时候就在表空间级的快照信息中检查这些，如果有临时数据I/O 高的证据，那么
我们就能从动态SQL 语句的快照或者静态SQL 事件监控数据中向下钻取。查找造成临时缓冲池中活跃的某个语句。
5.
假设现在我们已经确定了一个发生以上类型瓶颈的容器- 但是有时却会出现这种能情况，我们看不到任何明显的原因。没有繁忙的表，没有繁忙的索引，没有繁忙的SQL 语句。可以调查几种可能的原因。
1.在这个表空间中有太多… fairly active ?的表或索引吗？虽然它们中没有一个能自己活跃到足以导
致瓶颈的程度，它们聚集起来仍有可能相对于底层磁盘太过活跃了。一个解决方法是把这些表和
索引分布到不同的表空间。另外一个可能性是向这个表空间添加更多的容器（提供的这些容器位
于不同于现有容器所在的磁盘上，因此I/O 能力得到了提升。）
2.太多的表空间共享了同样的磁盘吗？这一不小心就可能发生，表面上表空间占用了不同的逻辑卷，
但是最终在最底层还是使用的同样的磁盘。像上面提到的，整体活跃- 这个时候越过表，表空间或许要承担全部责任。合理的反反应是把一些表空间挪到别的磁盘上。
如果在这点上我们没有找到发生容器磁盘瓶颈具体的原因，至少我们已经排除了大多数…可调整问题?，而且应该考虑增加而外的磁盘吞吐能力来提高这个…问题?表空的性能。
虽然容器磁盘瓶颈很普遍，日志磁盘瓶颈却能对系统更大的影响。这是因为日志速度降低能影响系统中所有的INSERT/UPDATE/DELETE 语句，不仅是某些表或索引。像其它类型的磁盘瓶颈最主要的症状就是
iostat/perfmon（90% 或者更高）。日志瓶颈也会造成事件监控器中的更长的提交时间，在应用程序快照中更多的代理程序处于… commit active ?状态。
如在这个章节提到过的对于日志配置，强烈建议在数据运行中，日志不和任何… active ?对像共享磁盘，比如容器，等等。这是在发生日志瓶颈的时候需要首先反复确认的事情之一。
如果日志有它自己的磁盘，那么我们需要了解瓶颈的性质。
1.如果iostat 显示日志设备每秒执行 80-100 个操作，并且平均的I/O 大小是4k 字节，这表
明日志饱和更多的发生在I/O 操作上而非完全是数据量导致的。
这种情况有两种可能。
o首先，系统中的一些应用程序可能提交得过于频繁- 或比需要的要频繁。高提交率的应用程序可以通过应用程序快照来确定（比较select/insert/update/delete 语句提交
率，并查看每分钟提交的数目）。在极端情况下（例如，自动提交开启，并且SQL 语
句都很短），是可能造成日志设备饱和的。在应用程序中减少提交频率对于减少日志瓶
颈有直接的好处。
o造成频繁日志写的另外一种可能是日志缓冲区太小。当日志缓冲满了，DB2 必须把它写入磁盘，而不管其是否提交。对于日志缓冲被迅速填满的情况（如sysibmadm.snapdb
的监视元素num_log_buffer_full 所报告的）很可能导致这个问题。
2.
3.
过多的数据写入同样可以造成日志瓶颈。如果随着设备利用率越来越高，iostat 也会显示写入日志设备的数据超过4k 字节很多，这表明比起高事务率，数据量对产生这个问题负有更多的责任。
4.或许根据你的具体环境可以降低记日志记录数据的量:
a.当DB2 更新表中的一行的时候，它会记录从第一个被更改的列到最后个被更改的列之间
的所有列- 包括那些没有被更改的列。在定义表的时候，将那些经常修改的列放在一起
能减少更新时日志记录的量。
b.大对像（CLOB,BLOB,DBCLOB）列默认是要记日志的，但是如过这些数据可以从数据库
之外恢复，从减少INSERT/UPDATE/DELETE 操作的时候日志记录的数据量，它们可
以适当的标记为NOT LOGDED 。
c.如果大量日志数据跟大批SQL 操作（比如，有子查询的INSERT，有时用于数据维护和
数据装载过程）有关，目标表或许能设置为NOT LOGGED INITIALLY（NLI）。这会
在当前工作单元不记日志。需要顾及到对NLI 表的可恢复过程；然而，如果适合你的
系统，NLI 可以非常明显的降低日志数据量和相应的提高性能。当然，如果这批操作是
直接INSERT，可以用load 使用工具替代，它也能同样地避免记录日志。
无论哪种情况- 不管是日志的高写入频率还是数据写入量高造成的日志瓶颈- 要消除问题的原因往往是不可能或者不切实际的。一旦我们确认日志配置遵循了上面描述的最佳实践，或许就需要通过提高日志系统的能力来解决问题。要么通过添加额外的磁盘到日志RAID 队列中，要么提供一个专门的或者升级了的磁盘缓冲控制器。
DB2 诊断日志路径― db2diag.log 存放的地方 - 繁重的磁盘写入能造成整个系统的性能下降，这很难分离，因为普通的 DB2 监控元素并不跟踪它。在多分区环境中所有分区都写入同样的诊断日志路径，它一般是通过网络共享 NFS 文件系统。类似于分区间同步，从许多分区对 db2diag.log 的并发写入可能会导致很高的网络通讯和 I/O 负载，并因此降低系统性能。正如在前面配置章节提到的，解决这个问题最简单的办法就是为每个分区指定一个单独的诊断日志路径（并指定一个专门的诊断日志文件）。
设置 DB2 的 diaglevel 数据管理配置参数为 4 会增加诊断信息的数据量，这会导致明显的性能影响 - 尤其在一个大型的多分区（DPF ）环境。性能急剧下降甚至可能造成 DIAGPATH
文件系统满并最终使系统停止。为了避免这种情况，你应该确认诊断日志文件系统有足够的可用空间，通过归档诊断信息或者分配一个专门的文件系统给 DB2 存放诊断信息。
图 1. 磁盘瓶颈 - 总图
回页首