很多应用程序所支持的服务水平协议（SLA）可以保证快速的运转，提供可接受的在线响应时间。而延长事务运行时间则会引起人们的担忧。这里有一些方法可供DBA使用以缓解这些问题。

　　运行时间

　　一般来说，对于我们所熟知的DB2数据库事务或是单个查询的运行时间，它们取决于多个因素，包括：

• 查询解释和DB2的访问路径选择
• CPU的速度及可用性
• 对存储介质的物理I/O访问
• 等待和加锁造成的延时
• 网络传输时间

　　以上因素中，对存储介质（通常是磁盘或是RAID存储）的物理访问是最为耗时的。而当存在I/O限制或是系统瓶颈时，访问则更为缓慢。因此，进行性能调优时，DBA通常会将精力放在减少I/O上。

　　试想有一个查询需要很长时间才能完成，那么我们需要采取什么样的步骤来加以解决呢？

　　第一步

　　DBA的首先要做的是找出那些造成长查询运行时间的罪魁祸首，包括：

　　1. 不正确的或是低效的数据访问路径

　　2. 长时间等待I/O的完成

　　3. 长时间等待数据锁定和释放

　　本文并不会花大篇幅讨论访问路径调优的话题，但还是会就一些通常的调优加以论述。对于DB2选用低效访问路径的一些最常见原因包括：

• 缺乏最新的统计信息
• 不良聚合数据
• SQL编码中预包含了优化器从而避开了某些访问路径
• 不良索引设计

　　而这些中的大部分问题可以通过以下策略加以解决。

　　对表进行设计以使数据能有效聚合。聚合意味着表中拥有相似键值的记录被紧密存储在一起。常见的例子如账户表：记录是以账户序号进行排序的，对于事务数据，事务是按物理因素进行排序的，如按事务日期排序。

　　聚合对于要访问大量记录的查询最为有效。以事务表为例，它们最常是按日期进行访问的。例如，一个查询可能会对本月中所有以日期标记的事务进行余额结算，统计数量或是按事务编号进行分类等。

　　良好的聚合使得表会按主键及外键进行连接。对于一个包含客户表和订单表的订单登记系统，就可以按它们的外键（对客户号和订单号分别进行）进行聚合。

　　对索引进行设计以支持常用的数据访问模式（扫描，连接）。正如前面所提到的，通过主键及外键相关联的应用程序表一般是连接在一起的。数据库设计者通常会在这些列上定义索引以允许在这些表连接的过程中可以对索引加以使用。索引在次键或搜索领域也是很常见的。因此，查询能够通过对索引的访问来达到访问数据的目的。因为索引要比它们的基表要小的多，所以这样便有利于减少物理I/O。

　　要确保在需要时可以执行表重组。当表数据改变或是进行插入，更新，以及删除SQL语句时，表中具有相似键记录的物理位置会彼此分离的更远。DB2的表重组功能就可以通过卸载，以聚合键排序，然后重载表来对这些物理数据的聚合序列加以恢复。

　　确保在需要时可以执行索引重组。与表的情况类似，更新活动同样会使表中的索引非聚合化。

　　确保保持最新的数据分布统计信息。DB2用其自带的实时统计设备（RTS）来维护表和索引上的数据分布统计信息。除此之外，DBA还可以用RunStats功能来收集诸如常用列值，数据倾斜，以及其他属性的额外统计信息。而想要获取更多信息可以参考相关的DB2手册。

　　统计信息是与查询本身一道被DB2优化器用来决定在总的CPU和I/O中拥有最小开销的数据访问路径。因此，强烈建议保持最新的统计信息。

　　进行了以上所有步骤之后要确保静态SQL被绑定。SQL以两种形式存在：动态和静态。动态SQL通常是被用户以专门的方式加以创建，如用查询开发工具或是报表工具。动态SQL在到达DB2数据库引擎的同时必须被分析和执行。静态SQL以硬编码的形式存在于应用程序中。当程序经过编译，DB2会将SQL语句和访问路径加以存储方便以后引用。这就意味着程序中SQL语句的数据访问路径是在编译时就预先确定好的。我们称预先存储数据访问路径以供后续使用的这种方式为调用绑定，而相应的SQL语句称为被绑定。

　　由于静态SQL语句访问路径是在是在绑定时间确定好的，所以以上所有策略必须在绑定时间之前完成。

　　再谈谈运行时间

　　经过了对访问路径的优化，DBA此时可以将精力转向查询执行的细节以确定是否可以减少长运行时间。一个常见的策略是把诸如CPU或可以用来补偿低速I/O的磁盘空间等未充分利用资源加以利用。这就是所谓的资源平衡。

　　资源平衡：磁盘空间

　　在有充足磁盘空间的情况下如何才能减少DB2的 I/O呢？一种方案是在一个表上创建多个索引。这些索引可能包含表列的一个主子集，这些列或许正是一般查询所要用到的。而在这种情况下，DB2就可以确定对表的最佳的访问路径就是通过该索引。实际上，如果查询所需的所有列都包含在索引中，这种访问路径就称为唯一索引。一般来说，索引需要占用的磁盘空间要远远小于表，而对类似索引的访问会涉及更少的I/O，从而便减少了物理I/O的数量。

　　另一种可选方案是数据压缩。DB2附带了一套硬件辅助数据压缩算法，DBA可以用其来定义一个表。加载到表的数据可以减少50%甚至对于字符数据可以高达80%。更小尺寸的表相应也就会占用更小的存储空间。同样，对表的访问也就会引起更少的物理I/O。

　　资源平衡：CPU

　　DBA可以通过两个称之为分区和并行的数据库设计思想来充分利用CPU周期。

　　分区就是将一个表分割成多个物理文件。最为常见的是水平分区。DBA指定一定数量的表分区，并指定如何将记录分配给各个分区。目前最为常用的设计是将键值在一定范围内的表记录包含在各个分区中。例如，一种常用方法是利用日期对数据仓库表进行分区，而各个分区都包含特定日，月或是日期范围的表记录。

　　并行理论是DBMS在逻辑上将数据库查询分割为多个片并对每片单独进行并行处理。例如，考虑这样一个针对某数据仓库表的查询，此查询用来请求某个年份的所有记录。同时假定此表是以月份来进行分区的。这样，每个分区就包含有此年份中特定月份的数据。现在DBMS就可以将以上的查询（内部或透明的）分割为12个类似的查询，而对这12个查询，除每个查询对应各自单独月份的访问记录外，其余都是等同的。如此一来，一个关于一整年数据的查询就变成了12个包含各自单独月份数据的相似查询。当然，DBMS同样必须取得12个月份的查询结果并将它们合并汇总为一份单独的结果给请求者。

　　现在我们可以看到这两种策略的结合使用是如何大幅减少物理I/O时间的。原始查询必须顺序访问表中12个月份的数据。而分割后的12个查询则可以被同时执行。这样，运行时间几乎可以成10倍的降低。I/O的数量在这两种情形下是基本一致的，但通过对表进行分区和并行，相同数量的I/O就可以由12个并行进程来完成。

　　资源平衡：内存

　　DB2从磁盘中读取表和索引数据并用内存块加以存储。我们称这些块或区域为虚拟池。DBA通过设置DB2中相应的配置参数来定义这些区域的大小，接着，在表和索引的定义中指定各个虚拟池与相应对象的对应关系。

　　在有充足内存可用的情况下，DBA可以针对某些对象和对应的查询大幅增加虚拟池的大小。例如，如果某些表被频繁使用，则DBA就可以为它们指定各自的缓冲池并分配一个较大的区域。当这些表被查询访问时，DB2就将它们读入内存。之后相关的对象就会发现它们仍存在于内存中，这就意味着DB2可以即时恢复数据而不用再从磁盘中读取。通过在内存中对表进行访问，DB2避免了物理I/O并大幅减少了运行时间。

　　总结

　　查询运行时间太长可以通过多种途径加以解决。首先，DBA必须确保表设计包含的数据聚簇良好，而且索引定义要合理。其次，DBA要同应用支持团队协作找出表重组的频度，以及何时收集更新数据的分布统计信息。最后，如果数据聚合或统计信息有所改变，静态SQL则需要以一定规律性的原则进行绑定。

　　一旦DBA完成了这些主要步骤，资源平衡的优势就会凸现出来。DBA可以利用CPU，磁盘空间，以及内存来减小运行时间。

　　注意：这里所讨论的大部分问题并不是要DBA等到首次执行查询时才去解决。合理的聚合，分区，索引选择以及重组和统计信息调度都是应该在数据库设计阶段进行的。

        相关阅读：详解基于DB2 z/OS环境下的数据库调优技术