应用程序设计方面的考虑

　　应用程序设计同样会影响到数据库。首要的一步就是要确保应用程序只要求数据库管理器做必需的工作。例如，通过使用 SELECT * 来请求所有的列在一定程度上可以使得程序的速度加快，但是这样做却降低了性能，因为需要额外的数据移动，而且阻止了“index only”扫描。在查询中包括不必要的子句，例如 ORDER BY 或者 DISTINCT ，就是请求数据库管理器做额外工作的一个例子。如果列的顺序对应用程序的运行没有影响，那么就可以省下排序所花的时间。

　　控制锁（locking）特性对于增加数据库的吞吐量非常重要。即使是对于只读事务，提交也具有极大的重要性，因为对于这样的事务同样也要使用锁。选择正确的隔离级别非常重要。应该使用尽可能低的隔离级别，只要在这种级别上应用程序能够运行就行了。对于锁来说，使用可重复读隔离级别是极其昂贵的，并且也减少了并发性。只要不打算对结果集进行更新，那么就应该包括 FOR READ ONLY 子句。这样就可以保证独占的锁不被获得。 FOR UPDATE 子句将消除对重新获得更高级别锁的需求。在某些环境下，在查询之前通过应用程序获得一个表锁可以防止获取很多的行锁，从而防止了对锁的逐步升级。

　　查询优化是另一个可以节省大量资源的方面。优化的级别可以通过数据库配置参数 dft_queryopt 进行设置。并且，在静态 SQL 中可以通过 PREP 和 BIND 命令进行重设，在动态 SQL 中可以通过 SET CURRENT QUERY OPTIMIZATION 语句进行重设。对于复杂的查询，可能需要第 5 级或者更高的级别。可以使用 db2batch 工具来评测花在编译和执行 SQL 语句上的时间。至于结果，要记住，静态 SQL 语句通常是编译一次，执行多次；对于动态 SQL 也是一样，因为结果要缓存。

　　初始调优

　　在创建了数据库和表空间之后，可以使用 Performance Wizard 来设置初始数据库配置。选择数据库以及“Configure Performance Using Wizard”选项。这将允许更快地装载数据。在创建了数据对象之后，就应该装载数据。

　　调优的第一步就是使用 RUNSTATS 命令收集统计信息。为了获得整套的统计信息，应该指定“WITH DISTRIBUTION AND INDEXES ALL”选项。 RUNSTATS 应该是数据库维护的一个常规的部分。应该根据数据库的更新率有规律地（每日，每周，每月）调用 RUNSTATS 。如果对数据作了大的更改（装载或者删除了大量的行），也应运行 RUNSTATS 命令。统计信息可用于决定对于一个查询来说哪一个访问计划是最有效的。在执行了 RUNSTATS 命令之后，受到影响的包应该重新绑定。

　　在此之后应该再次执行 Performance Wizard，这一次是为了指定要填充的数据库。Performance Wizard 将更改某些数据库配置参数。如果正确地解决了这些问题，那么由 Performance Wizard 产生的值通常会比较理想。Performance Wizard 使您可以在第一屏恢复先前的配置（如果有的话）。您应该认真阅读窗口中的解说。最后一屏将显示老的和新的数据库配置，并对所有的更改用粗体进行高亮显示。

　　如果在测试时性能不令人满意，那么就应该使用 Database System Monitor（参见 System Monitor Guide and Reference以了解细节），或者将问题的源头缩小至几个事务，来查探这一问题的起因。对于特定的查询，解释工具（参见 Administration Guide 以了解细节）提供了有关性能问题可能的起因的有价值的信息。根据这些信息，可以对索引结构或者数据库参数作出更改。

　　结束语

　　先前的讨论强调了调优时需要考虑的的一些主要方面。调优是一个反复的过程。随着时间的推移，数据库中的数据以及应用程序需要更改。这时，为了适应新的需要，应该对性能进行检测并对数据库作出更改。对数据库的配置参数或者其他方面所做的更改要有基准，要打破常规。在某些时候，有些更改看上去是对的，实际上却会对数据库产生负面的影响。希望大家通过上文的学习，都能够很好的掌握关于DB2数据库初始调优和设计方面的知识。