在开发过程的早期作出的很多设计决定对DB2应用程序和数据库的性能有着巨大的影响。本文为在z/OS环境中取得更好的性能提供了一些一般性的指南和建议。 一、简介 本文的目的是为IBM业务伙伴提供关于DB2 Universal Database?(UDB)for z/OS(后面将简称为 DB2)环境中DB2数据库性能的重要信息。本文试图从多处收集材料，并尽可能有效地将它们表述出来。本文无意包含很全面的范围，也不会包含很深的细节。 我曾打算讨论对DB2数据库的性能影响最大的一些因素。但是，并不是所有可能的情形都可以猜测到，也不是所有潜在的考虑都能顾及到，更不用说在期望的范围内对它们进行描述了。我希望本文可以为不同环境下的DB2用户提供一个通用的指南，以帮助他们取得最佳的DB2数据库性能。本文的目的是成为一个良好的起点，用以处理任何给定安装环境下的数据库性能问题。 本文的范围是数据库设计性能。DB2性能远不止这一部分，它肯定要受到数据库设计以外的很多因素的影响。例如，程序的编码逻辑和其中使用的实际的SQL语句，可以列为应用程序设计一类。DB2系统性能可以包括诸如安装选项、缓冲池大小设置、DB2相关地址空间的调度优先级等等之类的因素。 本文的焦点是DB2数据库的设计。不过，有时候这些性能因素类别之间的界线可能会有些模糊。例如，在某种安装环境下进行配置时，缓冲池大小的设置和数量的选择通常被认为是一项系统性能因素。但是，倘若是将特定的表空间和索引指派给那些缓冲池，那么这些因素又可以看作是数据库设计一类的因素了。 在这里，我假设读者对z/OS环境中的DB2有一个基本的理解。本文的头几页将讨论性能治理的一些基本概念和准则，以便进行“级别设置” 。我的建议有点综合的性质，因而不会总是具体地给出技术性的描述和语法。读者假如想了解关于这些内容的更具体的信息，那么应该去阅读关于用户本地所安装的DB2版本的最近的IBM文档。
12345678910下一页
本文的通用设计点是DB2 for z/OS V7。虽然DB2 for z/OS V8已经被公布，并且也普遍可用（generally available ，GA），但是大部分IBM客户极有可能需要几个月的时间才能实现用于他们的生产系统的DB2 V8 NFM（New Function Mode）。而且，这里还要考虑另外一个因素。虽然DB2的每个新版本在变得普遍可用之前，都已经在IBM及其客户环境下经过了广泛的测试，但是相对于一个还没有推广的、没有普遍使用的版本而言，客户们往往对于基于早先版本的DB2的一般建议和窍门更有信心（长时间积累的经验验证了这一结论）。我将提到DB2 V8的一些新特性，从性能的角度来看，这些新性能可能会影响数据库设计。 免责声明：本文中所包含的信息未经任何正式的IBM测试，而是以AS IS的形式发布的。对这些信息的使用和其中任何技术的实现，都由用户承担责任，并取决于用户的能力去评价它们和将它们整合到客户特有的操作环境。虽然IBM对于每一项都进行了审查，以求特定情况下的正确性，但不能保证在其他情况下也能得到相同的或类似的结果。试图将这些技术应用于他们自身环境的用户须自己承担风险。 二、性能准则和方法学 1. 何时考虑性能 考虑应用程序和数据库的性能特性的时机是在那些应用程序和数据库的初期设计阶段，也就是开发过程的开始阶段。对DB2应用程序和数据库所需的资源进行合理的估计，这有助于用户在开发过程的早期便对设计和实现作出恰当的决定。假如等到后期才来考虑访问数据库的应用程序的性能，那么为了取得适当的响应时间和生成批处理窗口而进行一些必需的修改时，就会更加困难，而且更加消耗时间。 2. 应该关注些什么 当从性能的角度进行设计时，将大部分的精力集中在重要DB2数据和程序上，这种做法比较明智。在确定是什么应用程序或事务构成这一重要的工作负载时，以下特征中的一条或几条将会适用：
上一页1234567下一页
1) 它们代表了总体业务工作负载的很大的百分比。 2) 它们有着要害响应时间需求。 3) 它们包括复杂的逻辑和/或数据访问需求。 4) 它们访问大量的数据。 5) 它们消耗大量的资源。 6) 与那些属于公司内部的应用程序相比，它们是直接与客户打交道的（通过 Web、ATM 等）。 3. 数据库设计 数据库的设计有两个阶段： 1) 逻辑数据库设计 2) 物理数据库设计 数据库的逻辑模型仅仅是对用户的所有数据需求的一种表示，它将这些需求变成一种范式。这种模型通常就是数据建模会议的输出或最终结果。该模型实际上很少被原原本本地实现。其实，该模型只是在考虑如何实际地构造数据和将数据存储在DBMS之前，对数据的一种理想化的看法。 在对数据库对象的架构进行了考虑之后，逻辑模型就被转化为物理模型。在设计的这个阶段，就需要较为具体地考虑数据访问需求和性能因素。在产生物理设计的这个过程当中，有两大要素，即表设计和索引设计。下面将较为具体地讨论这两个话题。 4. DB2性能治理的方法 为了确保DB2应用程序具备合格的性能，未雨绸缪胜于亡羊补牢。在设计DB2数据库的早期阶段就将性能因素考虑进来，这一点很重要。然后，在项目尽可能早的时候，建立一套符合Service Level Agreement(SLA) 的性能“基准线”测量方法，这样，便可以在展示的时候和应用程序被修改的时候，跟踪性能特性和趋势。同时还应该持续地监控DB2系统和应用程序，从而在大的问题完全发作之前进行猜测。 通常，很多客户只有到了应用程序开发项目的最后阶段才开始担心性能。但是通常没有什么好的理由需要等到那时才去考虑性能。更好的做法是，在指定了用户界面和处理逻辑之后，立即考虑数据库设计的性能特性。例如，在创建最佳索引时，应该将重要DB2工作（请参阅前面的讨论）中SQL语句的谓词作为主要指南。
上一页12345678下一页
即使您可以开发一个有效的初期设计，随着数据量的增加，或者在系统资源紧缺的时候，也仍有必要对应用程序和/或数据库作出修改。假如一个应用程序执行时的性能不合格，较为可取的做法通常是添加更多的列到现有的索引中，或者为一个表添加新的索引，这种做法是首选。而更改表的设计，或修改用户需求，抑或修改反规范化（de-normalizing）表，都不是很有吸引力的选择。 三、理解DB2性能 1. Rules-of-thumb Rules of thumb（经验法则，也称ROT）在规划、监控和优化DB2性能的时候很有用。ROT通常是基于以前的经验（比如在一段时间内观察到的平均值）或者更复杂公式的简化。 记住这样一个事实很重要，即ROT只对于粗略的估计有用，而对于具体的分析用处不大。假如只是在某一类的文档中看到了一些ROT，便欣然接受并作为精确的事实来引用，那么就会有危险。在最好的情况下，这些ROT是一种估计，而在最坏的情况下，这些ROT对于特定的DB2环境可能不成立。 您应该为自己的环境非凡开发这些ROT（或者对它们进行调节，以适应自己的环境的特性）。应确保ROT与实际经验相关，而不是盲目地接受，这样才能对它们更有信心。一开始的时候，使用那些在您特定环境以外被使用过或者被开发出来的ROT，这种做法可能有用。但是，当对您自己DB2系统中的适当数据进行收集、分析和编制文档之后，应该对这些ROT加以验证和修改。IBM Redbooks是关于ROT的一种很好的参考资料，这些ROT经常作为建议被包括在性能监控工具中。 另一方面的考虑是，ROT可能随着时间的推移而演变。硬件技术的发展，软件编程技术的提高，系统架构的变化，诸如此类的变化都可能使得ROT的可靠性降低，甚至变得无效。而使ROT随着时间变化的最大因素也许正是DB2本身新版本的发行。
上一页123456789下一页
2. DB2工作负载 磁盘I/O经常是影响响应时间的最大因素，但是通过查看GETPAGE(GP)请求，更轻易理解底层的性能问题。当监控DB2活动和分析报告时，GETPAGE的数量也许是DB2总体工作负载的最好的指示器。 某个安装环境下的很多DB2工作都可以无异议地归为以下几类： 1) 事务：事务是在事务治理器（例如CICS和IMS/TM）控制下运行的程序。其中的SQL通常比较简单，但是事务量比较重。事务必须为用户提供极好的响应时间，这样应用程序才不致于要长时间地等待它们所需的资源。通常，第一个调用事务的用户将承受读取索引和数据页的成本。随后的用户则经常可以发现有些资源已经在缓冲池中。 2) 查询：查询也是程序，经常在需要决策支持时执行它。其中的SQL可能非常复杂，但是工作量经常远不及事务。查询的用户经常要等上数分钟甚至数小时，这取决于为了产生用户所请求的结果集，需要对多少数据进行搜索。查询经常要引起对整个表的扫描，而对结果排序是这种类型的工作负载的另一种常见特征。 3) 批处理和实用程序： 批处理和实用程序通常处理大量的数据，并且经常以一种连续的方式处理数据。这些程序在给定的窗口中完成它们的处理，这一点很重要。批处理和实用程序往往是各种系统资源的消费大户，一旦它们挤在一起，经常会使工作负载逐步上升。 3. 规范化 规范化是分析应用程序所需的数据实体，然后将这些数据实体转化成一组设计良好的结构的一个格式化的过程。逻辑数据模型的一般设计目标是正确性、一致性、非冗余和简单性。而且，关系理论的信条也要求数据库要经过规范化。 有一些按照连续编号排列的规则（也叫 范式（form））可以用来很具体地定义规范化数据。大多数专家都会建议设计者尽量遵从前三条规则，由此得到的数据就可以说是符合第三范式。
上一页12345678910下一页
而将一个表反规范化（de-normalize）的意思是，违反该表之前遵从的一种或多种范式，从而修改规范化的设计。这种反标准化的过程经常是由于性能的原因而进行的。在大多数以关系数据库为主题的书籍当中，都可以找到关于规范化的更具体的信息。 4. DB2表空间类型 在一个定义好的DB2数据库中，实际的表必须在称作表空间（table space）的DB2对象中创建。用户可以在DB2中定义4种不同的表空间： 1) 简单表空间：简单表空间可以包含一个以上的DB2表。这种表空间由页构成，每个页可以包含该表空间中定义的任何表中的行。 2) 分段表空间：分段表空间可以包含一个以上的DB2表。这种表空间由页组构成，页组被称作段（segment）。每个段只能包含该表空间中定义的一个表中的行。 3) 分区表空间：分区表空间只能包含一个表。根据分区（partitioning）索引的键范围，这种表空间被分成数个分区。每个分区都被看作一个独立的实体，答应SQL和DB2实用程序对其进行并发处理。 4) LOB表空间：LOB 表空间只用于LOB（大型对象）数据。LOB包括三种数据类型：BLOB（二进制大型对象）、CLOB（字符大型对象）和DBCLOB（双字节字符大型对象）。 四、表空间与表设计方面的考虑 1. 记录大小和页宽 固定长度的记录要优于可变长度的记录，因为DB2代码专门为处理固定长度的记录进行优化。假如记录是固定长度的，那么就无需将其从存储它的初始页面转移到其他地方。而对于可变长度的记录，其长度可能会变得不再适合初始页，因此必须将其转移到其他页。之后，每当需要访问该记录时，就必须发生额外的页引用。DB2 UDB V8中的一种新特性答应在需要的时候修改（ALTER）某一列的宽度，这样一来，即使您不能确定将来数据长度的增长情况，也不再需要创建可变长度的记录。
上一页234567891011下一页
一个页中所能存放的记录的数目也是值得考虑的一个方面。DB2为页宽提供了很多选项（4KB、8KB、16KB和32KB）。一开始的时候，可以选择默认选项（4KB），假如行的长度很小，或者对数据的访问基本上是随机的，则更应该选择这一选项。不过，在有些情况下，则需要考虑使用更大的页宽。假如一个表中各行的长度要大于4KB，那么就需要使用更大的页宽，因为DB2不支持跨页（spanned）记录。 还有一些情况下，对于一条固定长度的记录，其总长度可能刚好比4KB的一半大一点点，这时一个页只能容纳一条记录。对于刚好比页宽的 1/3、1/4 大一点点的记录，情形也是类似的。这种设计不仅浪费DASD空间，而且，对于很多DB2操作，还需要消耗更多的资源。因此，对于这一类的记录，应该考虑使用更大的页宽，这样浪费的空间相对要少一些。 其他可能的页宽是8KB、16KB和32KB。页宽不是在CREATE TABLE语句中直接指定的。相反，表的页宽是由相应的缓冲池的页宽来确定的，这个缓冲池也就是为包含该表的表空间所指定的缓冲池。要了解更多细节，请参考DB2 SQL Reference手册中的CREATE TABLESPACE语句。 2. 反规范化方面的考虑 逻辑数据模型是数据的理想蓝图。物理数据模型才是对数据的现实的实现。规范化只关注数据的意义，而没有考虑对于访问数据的应用程序的性能需求。完全规范化的数据库设计在性能方面要受到质疑。 这种性能问题的最常见的例子是连接（join）操作。通常，规范化过程最终将相关的信息放入不同的表中。于是应用程序需要从多个这样的表中访问数据。关系数据库为SQL语句提供了从一个以上的表中访问信息的能力，这是通过 连接多个表来完成的。连接操作可能要消耗大量的资源和时间，这取决于表的数量以及这些表各自的长度。
上一页3456789101112下一页
像I/T中的很多事情一样， 这里也可以考虑一种权衡的方法。对于具有经常被请求的列的多个表，一种是复制其中的数据，一种是执行表连接，两者谁的成本更高呢？在逻辑数据库设计过程中，您可以毫无保留地规范化数据模型，然后再加入一定程度的反规范化，作为潜在的性能调优的一种选择。假如您确实打算反规范化，那么一定要为此制作完整文档：较具体地描述您所采取的反规范化步骤背后的原因。 3. 设计大型的表 访问非常大的DB2表时，相应地要消耗很多的资源：CPU、内存和I/O。在设计大型表的时候，为了提高性能，用户可以做的最重要的两件事是： 1) 实现分区。 2) 创建有用的索引。 下面将更具体地讨论这两个话题。 4. 使用分段的或分区的表空间 假如数据包括LOB，那么用户就必须创建LOB表空间。对于非LOB数据，一般需要在分区表空间和分段表空间之间进行选择，这很大程度上取决于要存储的数据量，在一定长度上也取决于相关应用程序所需的数据访问类型。简单表空间已经很少被推荐了。 下面列出了分段表空间相对于简单表空间的一些性能优势： 1) 对于包含多个表的表空间，当DB2取得用于某一个表的锁时，这个锁不会影响对其他表的段的访问。 2) 当DB2扫描一个表时，只是访问与那个表相关的段。而且，空段中的页不会被提取。 3) 假如一个表被删除，在执行COMMIT之际，它的段就立即可以为其他表所用，而不需要执行REORG实用程序。 4) 假如一个表中的所有行都被删除（即 mass delete），则在执行COMMIT之际，该表所有的段就立即可以为其他表所用，而不需要执行REORG实用程序。 5) mass delete执行起来要高效得多，并且要写的日志信息也更少一些。
上一页45678910111213下一页
6) COPY实用程序不会复制那些由mass delete操作或删除（DROP）一个表所造成的空页。 当表达到一定大小时，通过实现分区表空间可以提高易治理性和性能。假如预见到这样的增长，那么明智的做法是，在设计和创建表空间时将其定义为分区的。下面列出了分区表空间可以提供的一些潜在的优势： 1) 并行性：您可以使用DB2 UDB目前所使用的三种并行方式。查询并行（多条I/O路径）是在DB2 V3中引入的。Sysplex查询并行（一个DB2数据共享组中的多用户和多任务）是在DB2 UDB V5中引入的。到现在，DB2已得到极大的发展，并大大地增强了那些处理分区表空间的DB2应用程序的并行处理能力。通过增加一定的CPU时间，可以大大减少这些查询所需的时间。 2) 对部分数据进行操作：分区表空间答应DB2实用程序一次处理一个分区的数据，这样其他任务或应用程序就可以并发地对其他分区进行访问。按照类似的方式，您可以将mass UPDATE、DELETE或INSERT操作拆成多个不同的任务。除了增加可用性以外，这种技术还可以为减少完成这种DB2工作所需的时间提供潜力。 3) 对频繁访问的数据有更快的访问速度：假如分区索引可以将访问更频繁的行与表中其他的行分开来，那么就可以将这些数据放入到它们专用的分区中，并使用更高速的DASD设备。 通常，表越大，就越有理由将其创建为分区的表。但有时候为较小的表创建分区表空间也很有利。当将 查找（lookup）表与其他较大的分区的表相连接时，通过将查找表也进行分区，可以最大化并行度。 假如在连接谓词中使用分区键（partitioning key），最后还有一点考虑需要顾及。需要按分区键进行连接的表应该有相同数量的分区，并且应该在相同的值上断开。
上一页567891011121314下一页
5. 数据压缩 DB2提供了压缩一个表空间或分区中的数据的能力。这是通过在CREATE TABLESPACE语句中指定COMPRESS YES选项，然后对表空间执行LOAD或REORG实用程序来实现的。通过用较短的字符串替换经常出现的长字符串，可以压缩数据。这时会建立一个字典，其中包含了映射原始的长字符串与它们的替换值的信息。 在数据被存储之前压缩数据，以及在从外部存储设备读出数据时将数据解压，这都需要使用一定的CPU资源。但是，数据压缩也可以为性能带来好处，因为可以在更少的空间（包括DASD和缓冲池中的空间）中存储更多的数据，与未压缩的数据相比，这样可以减少同步读，减少I/O等。 在决定是否压缩一个表空间或分区时，要考虑下面一些事情： 1) 行的长度：行的长度越大（尤其是它接近页宽时），压缩的效率就越低。在DB2中，行不能跨页，您可能无法实现足够的压缩来使一页可以容纳多行。 2) 表的长度：对于更大的表空间，压缩更为有效。对于非常小的表，压缩字典的大小（8KB到64KB）有可能会抵消掉通过压缩所节省出来的空间。 3) 数据中的模式：对于特定的表空间或分区，数据中重复出现的模式的出现频率将决定压缩的效果。有大量重复字符串的数据有巨大的压缩潜力。 4) 对压缩的估计：DB2提供了一个独立的实用程序DSN1COMP，通过执行该实用程序可以判定压缩数据的效果。要了解关于运行该实用程序的更多信息，请参考DB2 Utilities Guide and Reference手册。 5) 处理成本： 压缩和解压数据时，要消耗一定的CPU资源。与使用DB2软件模拟程序相比，使用IBM的同步数据压缩硬件可以大大减少所消耗的CPU资源（当DB2启动时，它将判定硬件压缩特性是否可用）。
上一页6789101112131415下一页
