DB2 数据库设计：取得最佳性能的准则
作者：未知 来源：www.jz123.cn 发布时间：2007-10-14 4:50:59 发布人：圈圈
在开发过程的早期作出的很多设计决定对 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 文档。
本文的通用设计点是 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 对于每一项都进行了审查，以求特定情况下的正确性，但不能保证在其他情况下也能得到相同的或类似的结果。试图将这些技术应用于他们自身环境的用户须自己承担风险。
性能准则和方法学
何时考虑性能
考虑应用程序和数据库的性能特性的时机是在那些应用程序和数据库的初期设计阶段，也就是开发过程的开始阶段。对 DB2 应用程序和数据库所需的资源进行合理的估计，这有助于用户在开发过程的早期便对设计和实现作出恰当的决定。如果等到后期才来考虑访问数据库的应用程序的性能，那么为了取得适当的响应时间和生成批处理窗口而进行一些必需的修改时，就会更加困难，而且更加消耗时间。
应该关注些什么
当从性能的角度进行设计时，将大部分的精力集中在 重要DB2 数据和程序上，这种做法比较明智。在确定是什么应用程序或事务构成这一重要的工作负载时，以下特征中的一条或几条将会适用：
1、它们代表了总体业务工作负载的很大的百分比。
2、它们有着关键响应时间需求。
3、它们包括复杂的逻辑和/或数据访问需求。
4、它们访问大量的数据。
5、它们消耗大量的资源。
6、与那些属于公司内部的应用程序相比，它们是直接与客户打交道的（通过 Web、ATM 等）。
数据库设计
数据库的设计有两个阶段：
1、逻辑数据库设计
2、物理数据库设计
数据库的逻辑模型仅仅是对用户的所有数据需求的一种表示，它将这些需求变成一种范式。这种模型通常就是数据建模会议的输出或最终结果。该模型实际上很少被原原本本地实现。其实，该模型只是在考虑如何实际地构造数据和将数据存储在 DBMS 之前，对数据的一种理想化的看法。
在对数据库对象的架构进行了考虑之后，逻辑模型就被转化为物理模型。在设计的这个阶段，就需要较为详细地考虑数据访问需求和性能因素。在产生物理设计的这个过程当中，有两大要素，即表设计和索引设计。下面将较为详细地讨论这两个话题。
DB2 性能管理的方法
为了确保 DB2 应用程序具备合格的性能，未雨绸缪胜于亡羊补牢。在设计 DB2 数据库的早期阶段就将性能因素考虑进来，这一点很重要。然后，在项目尽可能早的时候，建立一套符合 service level agreement (SLA) 的性能"基准线"测量方法，这样，便可以在展示的时候和应用程序被修改的时候，跟踪性能特性和趋势。同时还应该持续地监控 DB2 系统和应用程序，从而在大的问题完全发作之前进行预测。
通常，很多客户只有到了应用程序开发项目的最后阶段才开始担心性能。但是通常没有什么好的理由需要等到那时才去考虑性能。更好的做法是，在指定了用户界面和处理逻辑之后，立即考虑数据库设计的性能特性。例如，在创建最佳索引时，应该将 重要DB2 工作（请参阅前面的讨论）中 SQL 语句的谓词作为主要指南。
即使您可以开发一个有效的初期设计，随着数据量的增加，或者在系统资源紧缺的时候，也仍有必要对应用程序和/或数据库作出修改。如果一个应用程序执行时的性能不合格，较为可取的做法通常是添加更多的列到现有的索引中，或者为一个表添加新的索引，这种做法是首选。而更改表的设计，或修改用户需求，抑或修改反规范化（de-normalizing）表，都不是很有吸引力的选择。
理解 DB2 性能
Rules-of-thumb
Rules of th
简介
本文的目的是为 IBM 业务伙伴提供关于 DB2 Universal Database (UDB) for z/OS（后面将简称为 DB2）环境中 DB2 数据库性能的重要信息。本文试图从多处收集材料，并尽可能有效地将它们表述出来。本文无意包含很全面的范围，也不会包含很深的细节。
我曾打算讨论对 DB2 数据库的性能影响最大的一些因素。但是，并不是所有可能的情形都可以预测到，也不是所有潜在的考虑都能顾及到，更不用说在期望的范围内对它们进行描述了。我希望本文可以为不同环境下的 DB2 用户提供一个通用的指南，以帮助他们取得最佳的 DB2 数据库性能。本文的目的是成为一个良好的起点，用以处理任何给定安装环境下的数据库性能问题。
本文的范围是数据库设计性能。DB2 性能远不止这一部分，它肯定要受到数据库设计以外的很多因素的影响。例如，程序的编码逻辑和其中使用的实际的 SQL 语句，可以列为应用程序设计一类。DB2 系统性能可以包括诸如安装选项、缓冲池大小设置、DB2 相关地址空间的调度优先级等等之类的因素。
本文的焦点是 DB2 数据库的设计。不过，有时候这些性能因素类别之间的界线可能会有些模糊。例如，在某种安装环境下进行配置时，缓冲池大小的设置和数量的选择通常被认为是一项系统性能因素。但是，倘若是将特定的表空间和索引指派给那些缓冲池，那么这些因素又可以看作是数据库设计一类的因素了。
在这里，我假设读者对 z/OS 环境中的 DB2 有一个基本的理解。本文的头几页将讨论性能管理的一些基本概念和准则，以便进行"级别设置" 。我的建议有点综合的性质，因而不会总是详细地给出技术性的描述和语法。读者如果想了解关于这些内容的更详细的信息，那么应该去阅读关于用户本地所安装的 DB2 版本的最近的 IBM 文档。
本文的通用设计点是 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 对于每一项都进行了审查，以求特定情况下的正确性，但不能保证在其他情况下也能得到相同的或类似的结果。试图将这些技术应用于他们自身环境的用户须自己承担风险。
性能准则和方法学
何时考虑性能
考虑应用程序和数据库的性能特性的时机是在那些应用程序和数据库的初期设计阶段，也就是开发过程的开始阶段。对 DB2 应用程序和数据库所需的资源进行合理的估计，这有助于用户在开发过程的早期便对设计和实现作出恰当的决定。如果等到后期才来考虑访问数据库的应用程序的性能，那么为了取得适当的响应时间和生成批处理窗口而进行一些必需的修改时，就会更加困难，而且更加消耗时间。
应该关注些什么
当从性能的角度进行设计时，将大部分的精力集中在 重要DB2 数据和程序上，这种做法比较明智。在确定是什么应用程序或事务构成这一重要的工作负载时，以下特征中的一条或几条将会适用：
1、它们代表了总体业务工作负载的很大的百分比。
2、它们有着关键响应时间需求。
3、它们包括复杂的逻辑和/或数据访问需求。
4、它们访问大量的数据。
5、它们消耗大量的资源。
6、与那些属于公司内部的应用程序相比，它们是直接与客户打交道的（通过 Web、ATM 等）。
数据库设计
数据库的设计有两个阶段：
1、逻辑数据库设计
2、物理数据库设计
数据库的逻辑模型仅仅是对用户的所有数据需求的一种表示，它将这些需求变成一种范式。这种模型通常就是数据建模会议的输出或最终结果。该模型实际上很少被原原本本地实现。其实，该模型只是在考虑如何实际地构造数据和将数据存储在 DBMS 之前，对数据的一种理想化的看法。
在对数据库对象的架构进行了考虑之后，逻辑模型就被转化为物理模型。在设计的这个阶段，就需要较为详细地考虑数据访问需求和性能因素。在产生物理设计的这个过程当中，有两大要素，即表设计和索引设计。下面将较为详细地讨论这两个话题。
DB2 性能管理的方法
为了确保 DB2 应用程序具备合格的性能，未雨绸缪胜于亡羊补牢。在设计 DB2 数据库的早期阶段就将性能因素考虑进来，这一点很重要。然后，在项目尽可能早的时候，建立一套符合 service level agreement (SLA) 的性能"基准线"测量方法，这样，便可以在展示的时候和应用程序被修改的时候，跟踪性能特性和趋势。同时还应该持续地监控 DB2 系统和应用程序，从而在大的问题完全发作之前进行预测。
通常，很多客户只有到了应用程序开发项目的最后阶段才开始担心性能。但是通常没有什么好的理由需要等到那时才去考虑性能。更好的做法是，在指定了用户界面和处理逻辑之后，立即考虑数据库设计的性能特性。例如，在创建最佳索引时，应该将 重要DB2 工作（请参阅前面的讨论）中 SQL 语句的谓词作为主要指南。
即使您可以开发一个有效的初期设计，随着数据量的增加，或者在系统资源紧缺的时候，也仍有必要对应用程序和/或数据库作出修改。如果一个应用程序执行时的性能不合格，较为可取的做法通常是添加更多的列到现有的索引中，或者为一个表添加新的索引，这种做法是首选。而更改表的设计，或修改用户需求，抑或修改反规范化（de-normalizing）表，都不是很有吸引力的选择。
理解 DB2 性能
Rules-of-thumb
Rules of th