runstats整理

RUNSTATS 是 DB2® Universal Database™（DB2 UDB）中的实用程序，它更新优化器为确定存取数据的最快路径所使用的目录统计信息。

  现在，几乎所有重要数据库都使用某种方法来更新目录统计信息，以便为其优化器提供可能的最佳信息。可以将优化器视为一个勘探器，正在系统中的数据所代表的大山中进行定位。目录统计信息的更新将为优化器提供最新的地图，以便在整个地形中快速定位。

DB2 优化器使用目录统计信息来确定最佳的访问路径，而更新这些目录统计信息所采用的主要方法就是运行 RUNSTATS 实用程序。当用户表中发生数据修改时，目录统计信息表不会自动被修改。必须在表和索引上执行 RUNSTATS 命令，用最新的信息更新目录表中的列。

可以查询下列目录列，确定是否在表和索引上执行了 RUNSTATS：

• 如果对于某个表，SYSCAT.TABLES 视图的 CARD 列显示的值为 -1，或者 STATS_TIME 列显示的值为 NULL，那么这表示没有对该表运行 RUNSTATS 实用程序。
• 如果对于某个索引，SYSCAT.INDEXES 视图的 NLEAF、NLEVELS 和 FULLKEYCARD 列显示的值为 -1，或者 STATS_TIME 列显示的值为 NULL，那么这表示没有对该索引运行 RUNSTATS 实用程序。

在第一次将数据载入到表中之后，就无法避免地要对表进行更新、删除和插入等形式的修改。可以添加或删除索引。特定列中的数据分布可能随时间发生改变。目录中不会反映这些修改，除非在这些表和索引上执行 RUNSTATS。一段时间之后，随着表和数据发生更改，目录统计信息可能会过时。

执行 RUNSTATS 是很重要的，但是频繁地运行可能会带来问题。对于较小的表，发出 RUNSTATS 命令将是一项普通任务。然而，随着表的增长，完成 RUNSTATS 命令将占用更多时间、CPU 和内存资源。最终，您必须考虑分配更多时间和资源来运行 RUNSTATS 与不执行该命令的潜在性能下降之间的平衡。通常只在关键查询的速度开始减慢时，管理员才会对 RUNSTATS 给予适当的注意。您可以通过制定高效、有效收集统计信息的策略，避免未经思考就调优查询和执行 RUNSTATS。

  理论上，应该在下列情况下对表和索引执行 RUNSTATS：

• 将数据载入表中并创建了合适的索引之后。不过，最好是在创建索引之后再执行 LOAD 命令，并在 LOAD 期间收集统计信息。
• 创建了一个新的索引之后。
• 使用 REORG 实用程序重新组织表之后。
• 通过数据更新、删除和插入大量更新表及其索引之后。
• 更改了预取（prefetch）大小之后。
• 运行 REDISTRIBUTE DATABASE PARTITION GROUP 实用程序之后。

您可以通过比较查询 RUNSTATS 之前和之后的 EXPLAIN 输出，来确定运行 RUNSTATS 对于访问计划的影响。

完成每一条 RUNSTATS 语句之后，您都应该执行显式的 COMMIT WORK。COMMIT 将释放锁，并避免在收集多个表的统计信息时填写日志。

在用 RUNSTATS 收集了统计信息之后，要使用 BIND 命令或 REBIND 命令重新绑定包含了静态 SQL 的包（并可以选择重新解释其语句）。 db2rbind 命令可用于重新绑定数据库中的所有包。使用 FLUSH PACKAGE 命令来删除包缓存器中当前所有缓存的动态 SQL 语句，并强制隐式地编译下一请求。

使用参考：db2 "runstats on table <scheam_name>.<table_name> and indexes all"

引自：http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0412pay/