DB2数据库设计和最高性能原则

这篇文章的目的是为了给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的新特性。

免责声明：本文包含的信息并没有提交给任何正式的IBM测试，并按"AS IS"原则提供。本信息的使用，或者是以上提到的任何技术的实现均由用户负责，且依靠用户的个人能力对其进行评估，并将其整合进入客户特定的操作环境中。其中的每一项都将在IBM特定的条件下获得精确的数值，这里不保证在其他地方会出现同样或者相似的结果。当用户尝试在各自的环境下采用上述技术时，需要自己承担风险。

性能原则和方法学

考虑性能的时机

考虑应用程序和数据库各自不同的性能特征的时间，是在对这些应用程序和数据库进行设计的初始阶段，即开发过程的一开始。对你的DB2应用程序和数据库所需要的资源进行合理评估，将会帮助用户在开发过程的早期对设计和实现做出适当的决定。如果你的应用程序访问数据库的性能直到后来才被说明，那么就要做必需的修改以获得足够的响应时间，并处理你的批处理窗口；这将会变得更加困难，并且消耗时间。

关注焦点

当设计性能的时候，将大部分的精力集中在重要的DB2数据和程序上是很明智的做法。对应用程序或者事务进行定义是这部分工作中的重点，以下一个或者多个特点是适用的：

它们表现了所有业务工作量中的大部分

它们有一个很关键的响应时间需求

它们包括了复杂的逻辑和/或数据访问需求

它们访问大量的数据

它们消耗大量的资源

它们直接与客户进行交互（通过网络、ATM等），与此相反，应用程序大多面向公司内部

数据库设计

数据库设计发生在以下两个阶段：

数据库逻辑设计

数据库物理设计

数据库的逻辑模型只是所有用户数据需求规格化的形式表现。这个模型通常是数据建模阶段的输出或者是最终结果。它很少在实际意义上被实现。更何况，在考虑如何在数据库管理系统中实际地组织和存储数据之前，它只是数据的一个理想化的视图。

当考虑到特定数据库对象的体系结构的时候，逻辑模型才会转化为物理模型。在这一设计阶段，才需要考虑到数据访问需求和性能因素的一些细节。在进行物理设计的过程中，两个关键的因素是表设计和索引设计。这两个问题将会在下面进行详细讨论。

DB2性能管理的方式

为了确保你的DB2应用程序有足够的性能，采取积极的态度总比消极应对有意义得多。在DB2数据库设计的早期阶段总结出性能因素是至关重要的。然后在项目中，努力尽早地确定满足你的服务级别协议（SLA）的性能“基线”的测量标准，这样你就可以在首次演示和应用程序变更的时候追踪性能特点及其发展趋势。不断地监测你的DB2系统和应用程序，以便在大多数的问题成形之前预见到它们。

传统意义上，许多客户都是直到应用程序开发项目的最后阶段才开始关心性能问题。但是这样的等待是毫无益处的。早在描述用户界面和处理逻辑的阶段就去思考数据库设计的性能特点，是比较有好处的。例如，在你的重要的DB2工作（见前面所述）中，创建最好的索引的一个基本的指导就是对SQL语句中的谓词的考虑。

即使是你开发出的最初设计是一个有效的设计，但是以下的若干修改仍然是必要的，例如对你的应用程序进行修改，或者数据库以卷的形式增长，或者是限制系统资源。如果现有的应用程序没有充分的运行，那么通常情况下你都会希望最好能够在现有的索引上面添加更多的列，或者在表上添加新的索引。不论改变表的设计，或者修改客户的需求，还是使表非标准化，通常情况下都不是好的选择。

理解DB2性能

单凭经验的方法

单凭经验的方法（又叫做ROT）在进行计划、监测，以及对DB2的性能进行优化时是很有用处的。ROT典型地基于以前的经验（例如，长时间的观测平均水平），或者是基于对比较复杂的公式进行简化。

记住下面这一点是很重要的，ROT对于粗略的估计有用，但是进行详细分析的时候就不行了。只是因为这些经验出现在某些文章中，就把它们作为性能的精确引证是很危险的。最好的情况下，它们是估计值；在最坏的情况下，它们对于你特定的DB2环境来说就是无效的。

ROT应该在你的环境中得到（或者是对其进行调整，使其适应你的环境）。它们应该与你的实际经验相联系，而不是被盲目接受，这样你才会对它们的值有信心。从那些在你的特殊环境之外得到的ROT开始也许会有些帮助。但是当你从你的DB2系统中收集、分析、记录了合适的数据之后，就需要对这些经验值进行校正或者修改。IBM的红皮书是一本有关ROT的值得阅读的资源，里面含有许多关于性能监测工具的推荐经验。

另一个要考虑的事项就是ROT需要持续一段时间。随着硬件技术的发展，软件编码的改进，系统的体系结构发生了变化，这使得ROT更加不可靠，甚至是完全错误的。随着时间的发展，使ROT发生改变的最大因素恐怕就是最新发布的DB2自身了。