IBM DB2 基本性能调整

核心提示： 索引与性能 索引的主要目的就是帮助DB2 数据库管理器快速的从表中查出记录，为表中经常被使用的列创建索引通常有助于数据存取和更新操作性能的改善，IBM DB2 基本性能调整(3)，此外，索引还考虑到当多重事务处理在同一时间里访问同一个表时候的更好的并发性；这样，extent大小和prefetch 大小，并且保持系统目

　　索引与性能

索引的主要目的就是帮助DB2 数据库管理器快速的从表中查出记录。为表中经常被使用的列创建索引通常有助于数据存取和更新操作性能的改善。此外，索引还考虑到当多重事务处理在同一时间里访问同一个表时候的更好的并发性；这样，行检索更加快速并且锁迅速被获取而且不必担心它长期的挂起。但是这些优势需要成本。索引会占用数据库空间，并且它们可能导致在插入和更新操作执行过程的轻微型能降低。 (所有插入操作和部分更新操作必须发生在表和它对应的索引中。)
那么怎么才能告诉你是否创建索引将改进性能？DB2 UDB 8.1封装了一个工具包来协助你，它可通过控制中心访问。它被称为设计顾问，它会捕获关于数据库的典型工作负荷以及推荐修改的特定信息，譬如根据提供的信息可以去创建新索引或删除未使用的索引。
RUNSTATS工具与性能
每当SQL语句被发送到到DB2 数据库管理器中处理时，SQL 优化器会去读取系统编目表来确定被引用的列的特性以及在被引用的表中时候已经定义了索引，同时被语句引用的每个表的大小也包括在内。根据这些得到的信息，优化器可以估算出能满足SQL语句需要的每一种数据存取路径的成本，然后推荐最佳的一个。 优化器用于做决策的数据库统计集合数据在系统编目表中是一个关键性的元素。所以，统计的变化可能导致选择存取路径的变化；如果信息丢失或过时，优化器也许选择出来的存取计划将导致SQL语句执行时间比正常的要长。
拥有合法的信息在SQL语句的复杂性增加的时候变得更加关键。当只引用一张表(没有定义索引)时，优化器选择的数量是有限的。但是，当多个表被引用时(每个表都有一个或多个索引) ，那么可供优化器选择的数量会大大加大。但不幸的是，优化器所使用的统计信息是不会自动得保持更新。反而必须阶段性地通过使用运行统计工具(RUNSTATS)重新生成。可以通过控制中心和命令行两种方式执行RUNSTATS工具。语法如下：
RUNSTATS ON TABLE [TableName] < WITH DISTRIBUTION | WITH DISTRIBUTION AND < DETAILED > INDEXES ALL | WITH DISTRIBUTION AND < DETAILED > INDEX [IndexName] > < SHRLEVEL [CHANGE | REFERENCE] >
或者
RUNSTATS ON TABLE [TableName] < [AND | FOR] < DETAILED > INDEXES ALL | [AND | FOR] < DETAILED > INDEX [IndexName] > < SHRLEVEL [CHANGE | REFERENCE] >
TableName 是需要收集(或者更新)统计信息的表的名称。IndexName 是需要收集或者更新统计信息的索引的名称。
注:被显示在角括号里(< > )的参数是可选的；方括号([ ])中的参数是必须的。
例如，更新存储在系统编目表中的关于表DEFAULT.EMPLOYEE的统计信息。你可以执行以下命令：
RUNSTATS ON TABLE DEFAULT.EMPLOYEE WITH DISTRIBUTION AND INDEXES ALL SHRLEVEL CHANGE
运行统计工具不会输出信息。但是，你能通过查询系统编目视图SYSCAT.TABLES的CARD, OVERFLOW, NPAGES, FPAGES列来观看它的结果。(如果这些列的值是21，就意味着统计信息尚未对该行所代表的对象起作用。)
那么应该多久去收集表的统计信息呢?理想状况下，你应该在下面一些事件之后去使用运行统计工具：
·　　　　 大量的插入、更新或删除操作 
·　　　　 导入操作 
·　　　　 装载操作 
·　　　　 在现有表中插入一个新的字段
·　　　　 创建新索引
·　　　　 表重组 
每当表的统计信息被收集或更新的时候，所有引用它的程序包都要被重新与它绑定这样优化器就可以利用新统计信息并且在可能的时候，会指出它们所包含的SQL语句的更好的访问计划。 如果重新绑定失败或者忘记重新绑定这些程序包可能导致动态sql操作执行起来会比静态sql操作要快（译者注：我对此不太明白，询问别人后得到的解释是：静态可能采取的一个费时间的路线，数据变了但访问的策略没有变；重新绑定就意味着重新改变访问策略），相反也适用。
最后，将它们放到一起
对DB2 UDB 系统或任一复杂RDBMS的调优，为了得到最佳的性能将会是一个长的过程。在这一系列专栏我通过对数据库的分析，解释了性能问题是如何典型地出现从一个或更多的下列： 
粗劣的系统(环境) 配置 
粗劣的实例配置 
粗劣的数据库配置 
粗劣的数据库设计 
粗劣的应用设计。
系统调优应该从DB2UDB注册变量，DB2 数据库管理器实例配置参量以及可能有对性能产生巨大影响的数据库配置参量开始。接下来再考虑缓冲池如何使用并且确定是否使用附加的缓冲池或不同的缓冲池大小会有所帮助。选择适当的表空间类型，extent大小和prefetch 大小，并且保持系统目录统计最新，最终完成基本性能调整。