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个底层驱动，配置的吞吐量将受到非常严重的降低。参见insertstorageBPpaperreferencehere和insertphysicaldatabasedesignBPpaperreferencehere更多信息请参见存储配置最佳实践。为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默认值可以不再是每个CPU10个。系统一旦激活maxservers就调整如下1.收集ps–elfk|grepaio的输出并且判断是否所有的异步I/O（AIO）核心进程（aioservers）消耗同样数量的CPU时间。2.如果是，maxservers可能太少了。增加10%的maxservers然后重复第一步。3.如果有些aioservers较其它的要使用更少的CPU时间，那么至少当前系统拥有它所需要的数目。如果多于10%的aioservers使用较少的CPU时间就降低10%的maxservers并重复第一步。AIO参数maxreqs应该被设置成MAX（NUM_IOCLEANERSx256,4096）.这个参数控制绝大多数突出的AIO请求。Hdisk参数queue_depth应该基于这个队列的物理硬盘数目。例如，对于IBM磁盘queue_depth的默认值是3并建议这个值是3xnumber-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,andSEMMNI）:25025600032kernel.msgmni（消息队列的标识数）:1024kernel.msgmax（一个消息的最大大小，字节）:65536kernel.msgmnb（消息队列的默认大小，字节）:65536DB2数据分区特性使用DB2数据分区特性（DPF），通常并不是纯粹由数据容量决定，而更多的是工作负载的性质。大多数DPF部署在数据仓库和商业智能上是一个常规的指导方针。对于大型的复杂查询环境DPF是被高度推荐的，因为它的share-nothing架构提供了优异的可扩展性。对于小一些的不大可能快速增长的数据集市（达到300GB），一个DB2企业服务器版本（ESE）配置是一个很好的选择。然而大型的或快速增长的BI环境将从DPF中获利。虽然处理一个完整DPF系统设计已经超出了这篇文章的范畴，但是一个CPU到分区的基本描述还算简单。一个典型的分区系统通常每个分区拥有一个处理器内核。例如，一个有N个处理器内核的系统可能有一个编目分区和N个数据分区。如果这个编目分区将被大量使用（例如，拥有单分区维度的表），那么它最好被分配一个处理器内核。如果这个系统将支持许多并发活动用户，就可能每个分区需要两个内核。作为一个一般性的指南，你应该在每个分区上计划大约250G活跃的裸数据。在InfoSphereBalancedWarehouse的文档中有关于DPF配置最佳实践的更深入的信息，也包含对于non-BalancedWarehouse部署的有用资料。代码页的选择和校验除了影响数据库性能的行为之外，代码页或代码集的选择和比较的顺序也许会对性能造成很大的影响。由于Unicode允许客户在他们的数据库中比传统单字节代码页呈现更多类型的字符串，使得Unicode的使用变得越来越普遍。事实上，它也是DB29.5的默认值。然而由于Unicode代码集使用多字节来呈现一些单独的字符，这将增加磁盘占用和内存需求。如，UTF-8代码集是一个最常用的Unicode代码集，每个字符使用一到四个字节。一个字符串从单字节代码到UTF-8代码集在迁移过程中的扩大因素是非常难预测的。因为它取决于多字节字符的使用频率。对于典型的北美内容，通常没有扩大。对于大多数西欧语言，音标字符的使用一般导致10%的扩大，但是您的成本会有所不同。此外，相对于单字节代码页，使用Unicode会导致额外的CPU开销。首先，如果发生了扩充，越长的字符串处理工作就越久。其次，也更显著的是，该算法采用更先进的Unicode整理序列，如UCA500R1_NO，这比系统整理的典型单字节代码要昂贵得多。而这完全是由于Unicode串行排序成文化正确性的方式的复杂性造成的。操作受到了包括排序，字符串比较，like（）处理以及创建索引的影响。如果正确显示你的数据Uincode是必须的，那么请仔细选择校验顺序如果数据库需要存储多语言的数据，并且数据正确的排序顺序非常重要，则应该使用一个文化正确性校验（比如UCA500R1_xxx）。不过请注意，由于一致性的关系，根据不同的数据和应用程序这将有1.5x到3x的性能消耗。在文化正确性校验中，有规范化和非规