DB2数据库设计和最高性能原则（1）
2024-07-21 02:41:30
供稿：网友
这篇文章的目的是为了给IBM(r)商业伙伴提供一些重要的信息，这些信息是关于DB2通用数据库（UDB）在z/OS(r) 环境下（以下简称DB2）DB2(r)数据库性能方面的。本文试图将来自多方资源的材料进行整合，然后尽量有效地将信息展示出来。本文尽量避免在范围上过于宽泛，以及过于深入细节。下面，我将要讨论那些最频繁影响DB2数据库性能的因素。我在这里并不涉及所有可能的条件和所有潜在的考虑，而是只局限于预期的范围之内。我希望这篇文章能够对DB2客户有一个总体的指导，从而使它们自己的环境中去获得DB2数据库的最适宜的性能。这篇文章将从如何在一个特定的安装中定制数据库的性能开始谈起。 这篇文章所涉及的范围是数据库设计性能。而DB2的性能包括的内容比这要多得多，除了数据库的设计之外，实际上还有很多其他的影响因素。例如，程序的编码逻辑，实际使用的SQL语句，都被划分在应用程序设计范围内了。影响DB2系统性能的因素包括了例如安装选项、缓冲池规模、DB2相关的地址空间的分配优先级等。本文的重点在于DB2数据库的设计。但是有些时候，这些影响性能的因素分类之间的界限有些模糊。例如，安装过程中对缓冲池的规模，选用缓冲池的数量进行的配置一般都被认为是系统性能因素。但是，当分配特定的表空间和那些缓冲池的索引的时候，就被认为是数据库设计所要考虑的了。 假设读者已经对z/OS环境下的DB2有了一些基本的了解。本文的前几页讨论了一些关于性能治理的基本概念和原则，以便于后面的理解。我的建议在本质上有些笼统，我总是避免过于纠缠技术细节或者语法等方面的问题。想要获得关于这些问题的具体信息，你可以查看IBM最近发布的有关安装在客户端的DB2的文档。 这篇文档主要着眼于z/OS V7环境下的DB2。虽然在z/OS V8下的DB2已经发布了，并且具有通用性，但是很可能还需要几个月的时间，IBM 的大多数客户才能够让他们的产品系统实现DB2 V8 NFM（新功能模式）。这里还有另一个需要考虑的问题：虽然每个新发布的DB2在正式通用之前，都会在IBM和客户环境中进行相当充分的测试，但是客户仍然很可能对基于前一版本的有关DB2的常见推荐和单凭经验的方法怀有更多的信心，而不是非常认同还没有发布，或者是没有获得普遍使用的新版本（由于验证结论的实际过程的时间长度和深度）。我会在文中提到一些可能会影响数据库设计性能的DB2 V8的新特性。 12345678910下一页 免责声明：本文包含的信息并没有提交给任何正式的IBM测试，并按"AS IS"原则提供。本信息的使用，或者是以上提到的任何技术的实现均由用户负责，且依靠用户的个人能力对其进行评估，并将其整合进入客户特定的操作环境中。其中的每一项都将在IBM特定的条件下获得精确的数值，这里不保证在其他地方会出现同样或者相似的结果。当用户尝试在各自的环境下采用上述技术时，需要自己承担风险。 性能原则和方法学 考虑性能的时机 考虑应用程序和数据库各自不同的性能特征的时间，是在对这些应用程序和数据库进行设计的初始阶段，即开发过程的一开始。对你的DB2应用程序和数据库所需要的资源进行合理评估，将会帮助用户在开发过程的早期对设计和实现做出适当的决定。假如你的应用程序访问数据库的性能直到后来才被说明，那么就要做必需的修改以获得足够的响应时间，并处理你的批处理窗口；这将会变得更加困难，并且消耗时间。 关注焦点 当设计性能的时候，将大部分的精力集中在重要的DB2数据和程序上是很明智的做法。对应用程序或者事务进行定义是这部分工作中的重点，以下一个或者多个特点是适用的： 它们表现了所有业务工作量中的大部分 它们有一个很要害的响应时间需求 它们包括了复杂的逻辑和/或数据访问需求 它们访问大量的数据 它们消耗大量的资源 它们直接与客户进行交互（通过网络、ATM等），与此相反，应用程序大多面向公司内部 数据库设计 数据库设计发生在以下两个阶段： 数据库逻辑设计 数据库物理设计 数据库的逻辑模型只是所有用户数据需求规格化的形式表现。这个模型通常是数据建模阶段的输出或者是最终结果。它很少在实际意义上被实现。更何况，在考虑如何在数据库治理系统中实际地组织和存储数据之前，它只是数据的一个理想化的视图。 上一页1234567下一页 当考虑到特定数据库对象的体系结构的时候，逻辑模型才会转化为物理模型。在这一设计阶段，才需要考虑到数据访问需求和性能因素的一些细节。在进行物理设计的过程中，两个要害的因素是表设计和索引设计。这两个问题将会在下面进行具体讨论。 DB2性能治理的方式 为了确保你的DB2应用程序有足够的性能，采取积极的态度总比消极应对有意义得多。在DB2数据库设计的早期阶段总结出性能因素是至关重要的。然后在项目中，努力尽早地确定满足你的服务级别协议（SLA）的性能“基线”的测量标准，这样你就可以在首次演示和应用程序变更的时候追踪性能特点及其发展趋势。不断地监测你的DB2系统和应用程序，以便在大多数的问题成形之前预见到它们。 传统意义上，许多客户都是直到应用程序开发项目的最后阶段才开始关心性能问题。但是这样的等待是毫无益处的。早在描述用户界面和处理逻辑的阶段就去思考数据库设计的性能特点，是比较有好处的。例如，在你的重要的DB2工作（见前面所述）中，创建最好的索引的一个基本的指导就是对SQL语句中的谓词的考虑。 即使是你开发出的最初设计是一个有效的设计，但是以下的若干修改仍然是必要的，例如对你的应用程序进行修改，或者数据库以卷的形式增长，或者是限制系统资源。假如现有的应用程序没有充分的运行，那么通常情况下你都会希望最好能够在现有的索引上面添加更多的列，或者在表上添加新的索引。不论改变表的设计，或者修改客户的需求，还是使表非标准化，通常情况下都不是好的选择。 理解DB2性能 单凭经验的方法 单凭经验的方法（又叫做ROT）在进行计划、监测，以及对DB2的性能进行优化时是很有用处的。ROT典型地基于以前的经验（例如，长时间的观测平均水平），或者是基于对比较复杂的公式进行简化。 上一页12345678下一页 记住下面这一点是很重要的，ROT对于粗略的估计有用，但是进行具体分析的时候就不行了。只是因为这些经验出现在某些文章中，就把它们作为性能的精确引证是很危险的。最好的情况下，它们是估计值；在最坏的情况下，它们对于你特定的DB2环境来说就是无效的。 ROT应该在你的环境中得到（或者是对其进行调整，使其适应你的环境）。它们应该与你的实际经验相联系，而不是被盲目接受，这样你才会对它们的值有信心。从那些在你的非凡环境之外得到的ROT开始也许会有些帮助。但是当你从你的DB2系统中收集、分析、记录了合适的数据之后，就需要对这些经验值进行校正或者修改。IBM的红皮书是一本有关ROT的值得阅读的资源，里面含有许多关于性能监测工具的推荐经验。 另一个要考虑的事项就是ROT需要持续一段时间。随着硬件技术的发展，软件编码的改进，系统的体系结构发生了变化，这使得ROT更加不可靠，甚至是完全错误的。随着时间的发展，使ROT发生改变的最大因素恐怕就是最新发布的DB2自身了。 DB2工作量 磁盘I/O通常是影响响应时间的最大因素，但是，通过查看GETPAGE (GP)需求可以更轻易地看到潜在的性能问题。当监测DB2的活动并进行报告分析的时候，GETPAGE的数量很可能就是显示DB2整体工作情况的最好的指示器。 大部分的DB2安装工作可以分为以下几个较清楚的类别： 事务：这是运行在事务治理器控制之下的程序，例如CICS 和 IMS/TM。SQL通常比较简单，但是事务卷是很繁重的。事务必须为用户提供非常及时的响应时间，这样应用程序才不会被迫等待很长的时间以获得所需的资源。通常是第一个用户调用事务时才会产生读取索引和数据页的I/O开销。随后的用户可以在缓冲池中访问部分资源。 上一页123456789下一页 查询：这是通常情况下为决策支持运行的程序。其中的SQL也许十分复杂，但是卷通常要比事务的卷轻松许多。查询用户通常需要等待几分钟，甚至是几个小时，具体时间依靠于产生用户需要的结果集所查询的数据量。查询通常会调用针对整个表的扫描，并且对结果排序也是此类工作量的另一个常见特点。 批处理和实用工具集：批处理和实用工具集程序需要处理大量的数据，并且通常是以顺序的方式处理数据。在特定的窗口中结束处理对于这些程序来说是很重要的。多次使用位置正确的COMMIT（提交）语句是这些应用程序具有的一个很重要的特点。批处理和实用工具集通常需要消耗大量的各类资源，进行压缩的时候，通常可以逐步提高工作量。 标准化 标准化是应用程序进行数据实体分析的标准化过程，最终将把数据实体转换为一系列经过良好设计的结构体。通常，逻辑数据模型的设计目标是正确性、一致性、没有冗余和简单化。而且，关系理论原则也需要数据库进行标准化。 还有几条连续编号的规则，被称为范式，它可以相当具体地定义标准化数据。我在这里并不具体讨论这些规则。大多数的专家都会建议设计者们尽力遵循前三条的规则，因此这样的数据可被称为遵循第三范式。 对表进行非标准化的意思是，对一个先前遵守范式的表进行修改，使其违反一条或者多条范式规则。有时候，由于性能的原因，确实需要进行这个非标准化的过程。有关标准化的更进一步的具体信息，你可以在大多数的讲述关系数据库的书籍中找到。 DB2表空间的类型 在定义DB2数据库的时候，实际的表必须在被成为表空间的DB2对象中进行创建。用户可以在DB2中定义四种不同类型的表空间，如下所示： 单一：一个单一的表空间可以包含多于一个的DB2表。这个空间由多个页组成，每个页都可以包含若干行，它们可能是来自表空间中定义的任何表的数据行。 上一页12345678910下一页 分段：分段表空间可以包含多于一个的DB2表。这个表空间由多组页组成，每组页被称为一个段。每个段包含来自表空间中定义的某一个表的若干行。 分区：分区表空间只可以包含一个表。这个空间根据分区索引的要害值范围被划分成多个区。每个分区都作为一个独立的实体对待，答应SQL和DB2实用工具集的并发处理。 LOB：LOB表空间只存储LOB（大对象）数据。LOB包括了3个数据类型：BLOB（二进制大对象）、CLOB（字符型大对象），以及DBCLOB（双字节字符型大对象）。 表空间和表设计考虑事项 记录尺寸和页尺寸 固定长度的记录比可变长度的记录要好，因为处理固定长度记录的DB2的代码经过了优化。假如记录是固定长度的，那么它就永远不需要从原来存储的页中被移动出来。然而，可变长度的记录可能增长到不再适合原来页的长度，因此它也就必须被移动到另一页。无论何时记录被顺序访问，都一定会出现一个额外的参考页。DB2 UDB V8中的一个新特性就是当你不确定未来的数据长度增长情况时，答应你根据需要改变列的尺寸，这样你就可以不再需要创建可变长度的记录。 每页中记录的数量也是需要考虑的内容。DB2提供了一些有关页尺寸的选项，例如4 KB, 8 KB, 16 KB和32 KB 。比较好的起点是选择默认的4KB，非凡是当行的尺寸相对较小，或者是对数据的访问比较随机的情况下。然而，在一些情况下，也需要考虑较大的页尺寸。假如表中单个行的长度超过4KB，那么你就需要使用大一些的页尺寸，因为DB2不支持跨行的记录。 还有另一种情况是，当固定记录的总长度比二分之一的页（4KB）稍大一些的时候，一页中就只能放置一个记录。另外一种类似的情况是，固定记录的总长度略长于三分之一页、四分之一页，等。这样的设计不仅会浪费DASD空间，还会导致很多的DB2操作消耗更多的资源。因此，对于上面描述的记录而言，你需要考虑使用较大的页尺寸，这样就会相对地少浪费一些空间。 上一页234567891011下一页 另外一些可能的页尺寸为8 KB, 16 KB和 32 KB。页的尺寸并不在创建表（CREATE TABLE）的语句中直接写明。相反，表中页的尺寸是由分配给包含这个表的表空间的缓冲池中的页尺寸决定的。要获得更具体的信息，你可以参考DB2 SQL 手册中有关创建表空间（CREATE TABLESPACE）语句的内容。 非标准化考虑事项 逻辑数据模型是数据的一个理想描述。物理数据模型则是数据在现实世界的实现。标准化只集中在数据的内涵上面，而不考虑可能访问数据的应用程序的性能需求。数据库设计的充分标准化会带来性能的挑战。 有关此类性能问题的一个非经常见的例子就是连接操作。通常情况下，标准化过程的结果是给各个独立的表赋予相互关联的信息。应用程序需要从这些表中访问数据。关系数据库提供了使用SQL语句来从多于一个的表中通过连接多个表去访问信息的能力。取决于表的数目和它们各自的尺寸，连接操作可能会消耗非常多的资源和时间。 因为在I/T中有如此多的事情需要考虑，于是出现了一个折中的想法。对那些包含被频繁访问列的多个表中的数据保存副本，与连接表的性能相比，成本高还是低呢？在逻辑数据库设计过程中，对你的数据模型尽量的执行标准化，之后再对其进行一定程度的非标准化，也许是进行潜在性能优化的一个选项。假如你决定进行非标准化了，要确保从头到尾地记录了文档：对某些细节的描述、执行非标准化步骤之后的推理，等。 设计较大的表 访问很大的DB2表需要消耗相当多的资源：CPU，内存，I/O。当设计大表的时候，用户需要做的两件最重要的事情就是： 实现分区 创建有用的索引 以上两个问题将在下面进行具体讨论。 使用分段或者分区表空间 上一页3456789101112下一页 假如数据中包含了LOB，那么用户就必须创建LOB表空间。对于非LOB的数据，通常的选择是分段或者分区表空间，具体选择哪一个在很大程序上取决于你要存储的数据量，同时还需要考虑相关应用程序需求的数据访问类型。不太推荐使用单一的表空间。 分段表空间比单一的表空间具有更多的性能优势，如下所示： 对于包含多于一个表的表空间，当DB2在一个表上获得锁定时，那个锁定不影响其他表分段的访问。 当DB2扫描一个表时，只访问与那个表相联系的分段。此外，空分段的页不会被取出。 假如一个表被清除了，不需要执行REORG实用工具集，它的分段就立即在COMMIT点上变成可再次使用的状态。 假如一个表中的所有行被删除了（被称为块删除），不需要执行REORG实用工具集，所有的分段都立即在COMMIT点上变成可再次使用的状态。 块删除操作起来更加有效，并且书写相当少的记录信息。 COPY（复制）实用工具集不复制由于块删除或者表清除所造成的空页。 当表达到一个特定的尺寸，它们的可治理性和性能都可以通过分区表空间获得改善。假如你想获得这方面的进展，在设计和创建时，以分区的形式定义表空间是一个明智的做法。分区表空间的一些潜在优势列举如下： 并行性：你可以利用三种类型的并行性，它们目前正应用于DB2 UDB。DB2 V3引入了查询并行性（多个I/O路径）。DB2 V4则实现了CP并行性（多CP之上的多任务）。DB2 UDB V5更是引入了系统查询并行机制（多个DB2数据共享群之上的多任务）。DB2的发展进化，显著提高了DB2应用程序处理分区表空间的并行处理能力。由于CPU时间的增加，这些查询所消耗的时间也显著的减少了。 在数据的一部分上工作：分区表空间答应DB2应用程序一次运行数据的一个分区，因而使其能够同时运行另外分区上的另外的工作或者应用程序。以同样的方式，你可以将块UPDATE（更新）、DELETE（删除）或INSERT（插入）操作分解为独立的工作。除增加了可用性之外，这一技术也为完成这类DB2工作减少消耗的时间提供了可能。 上一页45678910111213下一页 更快的访问被频繁访问的数据：假如分区索引能够将更多的频繁访问的行从剩余的表中分离出来，然后将那些数据置于一个它自己的，并且应用更高速DASD设备的分区之内。 一般而言，表越大，就越应该将其创建为一个分区的表。但是也有一些实际例子表明为小表创建分区表空间是有利的。当查找表用于连接其他大分区表空间时，通过将查找表分区，你能够使并行性在连接中最大化。 当你在连接谓词中利用分区方法时，需要考虑一个决定性的因素。被连接在分区方法上的表应该具有相同的分区数，并且应该设定为相同的值。 数据压缩 DB2提供了压缩表空间或分区内数据的功能。通过指定CREATE TABLESPACE（创建表空间）语句中的 COMPRESS YES（压缩许可）选项，之后在表空间上同时执行LOAD或REORG实用工具集，即可完成该功能。数据的压缩是通过用更短的串来替换频繁出现的字符串实现的。系统还创建了一个字典，包含了原始字节串和它们的替代串之间的映射信息。 一定数量的CPU资源被用于在执行数据存储对其进行压缩，之后，当外部存储设备读取时，数据又被解压缩。然而，数据压缩也能够提供性能方面的好处，因为更多的数据存储在更小的空间内（在DASD上和缓冲池中）；同未经压缩的数据相比，这样可以产生更少的同时读取、更小的I/O等。 接下来是当试图决定是否压缩一个表空间或分区时，需要考虑的一些事情： 行的长度：行越长（尤其是在接近页的尺寸时），压缩的有效性就越低。DB2的行不能够跨页，当一页上有多于一行的情况时，你也许不能获得足够的压缩。 表的尺寸：对于较大的表，压缩具有较好的效果。对于很小的表，压缩字典的大小（8KB到64KB）可能会抵消压缩节省下的所有空间。 上一页567891011121314下一页 数据中的模式：对于一个特定的表空间或分区，数据中重复出现的模式的频率，决定了压缩的效果。含有大量重复字符串的数据能够获得显著的压缩效果。 压缩估计：DB2提供了一个单独的实用工具集，DSN1COMP，它可以用来测定数据压缩将有怎样的效果。想获得有关运行该使用工具的额外信息，请参考DB2实用工具集指南和参考手册。 处理成本：在压缩和解压缩DB2数据时，会消耗一些CPU资源。假如你用IBM的同步数据压缩硬件特征，所消耗的CPU资源将比利用DB2软件仿真程序低得多（当DB2启动时，这决定了硬件压缩特征是否可用）。 更好的字典：当用LOAD使用工具集来建立压缩字典时，DB2用户用最初载入的n行（n取决于你能够压缩的数据量）来决定字典的内容。REORG采用取样技术来建立字典。它不仅使用最初载入的n行，还在实用工具执行UNLOAD（未载入）阶段的剩余时间里继续对数据行采样。 通常情况下，我们推荐你在自己的特定环境下，压缩那些DB2表空间和分区，这将会使你的环境受益；因为在更小的空间内存储更多的数据的性能优势，几乎总是在价值上超过压缩和解压缩数据所消耗的CPU资源。 载入大表 在处理大批量数据时，将数据初始载入表中可能会对系统性能产生挑战。为了在载入过程中实现并行性，你可以手动创建多个LOAD作业，每个分区建一个；或者作为另一个选择，你可以在一个LOAD程序中载入多个分区。每个分区都延伸至I/O子系统，这种方式可以更轻易地实现最理想的并行性。 为了使性能最优化，在LOAD语句中指定SORTKEYS参数也很重要。这个参数指示DB2将索引方法传递给内存中的分类程序，而不是将要害字写入或者再次读取DASD上的排序任务文件。SORTKEYS也能够实现载入和分类之间的交迭，因为分类是作为一个独立的任务运行的。 上一页6789101112131415下一页
