使用针对工作负载的正确的性能调节技术，以避免硬件升级和优化DB2性能
　　性能通过响应时间，吞吐量，峰值响应时间，命中，和每秒会话来衡量。SQL编码和调节技术直接影响性能。开发高性能的DB2应用需要对DB2技术的深入了解。
　　当然在小数据量时这些技术无足轻重。忽略的连接，子查询，表的表达式和CASE表达式的程序完全可以在轻量级负载下工作的很好。使用100%的SELECT INFO语句来进行数据获取的程序，在开始会非常的迅速。但是一旦数据量和会话速度增加，性能将受到很大影响。DB2的可扩展性需要小的，优化的SQL加上方案设计，性能结构，缓冲池，和针对工作负载模式优化的存储。另外的方案就是升级硬件了。当然对于有着硬件升级的无尽预算的人来说，不用阅读本文了。对于其他人，我将讲解如何编码聪明的SQL以及调优的访问路径。
　　指针对于DB2性能的影响
　　曾经有段时间，在一个大的复杂的银行应用程序中存在着一个批处理程序。这个新的批处理程序和访问路径被通过代码走查的方式检查过了。因为项目截止日期的原因测试很少;在实际的首次运行中，程序在运行10个小时之后终止了。一个很慢的代码走查之后，发现了7个指针，每个指针访问一个不同的表中的数据。每个指针在其他打开的指针的循环中被打开，在彼此间传递数据。也就是说，这个程序在DB2以外竟然结合了7个表。这不是聪明的SQL.这个信息需要进入到7个表;然而，每个指针只能进入一个。因此，7个指针被合并为一个聪明的指针：
　　SELECT COL1, COL2, rest of the columns
　　FROM ADDR A, NAME N, T3, T4, T5, T6, T7
　　WHERE A.COL1 = N.COL9
　　AND N.COL9 = T3.COL3
　　AND T3.COL3 = T4.COL4
　　AND T4.COL4 <> T5.COL5
　　AND T4.COLX <> T5.COLY
　　AND T5.COL6 = T6.COL6
　　AND T6.COL6 = T7.COL7
　　AND T6.CODE = :hv
　　这个批处理在第二天用了四分钟就完成了。大多数人可能会结束这个成功的任务了，但是务实的人不会。一个缓慢的EXPLAIN信息走查发现了一个有趣的表连接序列问题。优化器选择了开始7个表的复杂的循环连接，还使用了一系列的大的数据表(ADDR和NAME)，它们每个都包含5千万行数据。这不是DB2优化器的典型行为。然而，有一些使用<>比较小表之间列的连接情况。这些比较对于优化器来说很难估计，因为DB2 catalog包含了相等列而非不等列。这里就需要访问路径优化了。DB2优化者脑中肯定有多种推荐的解决方案，一些可以在包或语句层次上，另外的一些工作在谓词层次。当然还有其他一些传统方式不奏效情况下的终极技术。一个要求就是如下的性能调节技术提供给你的catalog以足够的统计，使用统计向导来保证优化器有关于你的数据的精确全景。
　　DB2性能调节技术
　　包级别的SQL调优--需要REOPT(ONCE/ALWAYS/AUTO) BIND选项。这个语句通告优化器来在运行时重新优化包中的每个语句，至少ONCE,或者ALWAYS(每次执行)，在DB2 9中可以AUTO(需要时)。这项技术的开销由选择的选项和SQL语句的数量及复杂性决定。这些开销在批处理程序中可以忽略不计，但是在短期运行的交易中会有很大影响。在我们的例子中，批处理程序指针只有一个谓词和一个基数为1的主机变量。REOPT是一个调节选项，用来优化非统一列值分布和主机变量内容高可变的情况，是COLCARDF=1的反面。包级别的调节并不合适。
　　语句级别的调节技术--包括OPTIMIZE FOR n ROWS和FETCH FIRST n ROWS ONLY.这些语句，放在SELECT语句末尾，是在不需要结果集的情况下进行优化的。优化器假设除了这些语句的所有的SELECT语句需要整个结果，这些结果偏向于诸如数序和表预取的访问路径。因为我们的批处理指针一定需要整个结果，因此语句级别的调节也不是合适的技术。