1. 何时考虑性能

　　考虑应用程序和数据库的性能特性的时机是在那些应用程序和数据库的初期设计阶段，也就是开发过程的开始阶段。对DB2应用程序和数据库所需的资源进行合理的估计，这有助于用户在开发过程的早期便对设计和实现作出恰当的决定。如果等到后期才来考虑访问数据库的应用程序的性能，那么为了取得适当的响应时间和生成批处理窗口而进行一些必需的修改时，就会更加困难，而且更加消耗时间。

　　2. 应该关注些什么

　　当从性能的角度进行设计时，将大部分的精力集中在重要DB2数据和程序上，这种做法比较明智。在确定是什么应用程序或事务构成这一重要的工作负载时，以下特征中的一条或几条将会适用：

　　1) 它们代表了总体业务工作负载的很大的百分比。

　　2) 它们有着关键响应时间需求。

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

　　4) 它们访问大量的数据。

　　5) 它们消耗大量的资源。

　　6) 与那些属于公司内部的应用程序相比，它们是直接与客户打交道的（通过 Web、ATM 等）。

　　3. 数据库设计

　　数据库的设计有两个阶段：

　　1) 逻辑数据库设计

　　2) 物理数据库设计

　　数据库的逻辑模型仅仅是对用户的所有数据需求的一种表示，它将这些需求变成一种范式。这种模型通常就是数据建模会议的输出或最终结果。该模型实际上很少被原原本本地实现。其实，该模型只是在考虑如何实际地构造数据和将数据存储在DBMS之前，对数据的一种理想化的看法。

　　在对数据库对象的架构进行了考虑之后，逻辑模型就被转化为物理模型。在设计的这个阶段，就需要较为详细地考虑数据访问需求和性能因素。在产生物理设计的这个过程当中，有两大要素，即表设计和索引设计。下面将较为详细地讨论这两个话题。

　　4. DB2性能管理的方法

　　为了确保DB2应用程序具备合格的性能，未雨绸缪胜于亡羊补牢。在设计DB2数据库的早期阶段就将性能因素考虑进来，这一点很重要。然后，在项目尽可能早的时候，建立一套符合Service Level Agreement(SLA) 的性能“基准线”测量方法，这样，便可以在展示的时候和应用程序被修改的时候，跟踪性能特性和趋势。同时还应该持续地监控DB2系统和应用程序，从而在大的问题完全发作之前进行预测。

　　通常，很多客户只有到了应用程序开发项目的最后阶段才开始担心性能。但是通常没有什么好的理由需要等到那时才去考虑性能。更好的做法是，在指定了用户界面和处理逻辑之后，立即考虑数据库设计的性能特性。例如，在创建最佳索引时，应该将重要DB2工作（请参阅前面的讨论）中SQL语句的谓词作为主要指南。

　　即使您可以开发一个有效的初期设计，随着数据量的增加，或者在系统资源紧缺的时候，也仍有必要对应用程序和/或数据库作出修改。如果一个应用程序执行时的性能不合格，较为可取的做法通常是添加更多的列到现有的索引中，或者为一个表添加新的索引，这种做法是首选。而更改表的设计，或修改用户需求，抑或修改反规范化（de-normalizing）表，都不是很有吸引力的选择。