--自己的结论：

REOGCHK 不要轻易做，应该算dba 的事 ，发现表A比较慢，经常做大批量dml，导致表A的数据物理上分散严重，这个时候需要做。

runstatus 如果 JOBA 的目标为 TA并且做了大量的DML（10%-20%） ,JOBB 引用 TA做SELECT，则需要在 JOBA 与JOBB 之间做runstatus

RUNSTATS与REOGCHK

　　Runstats这个命令的功能主要就是收集数据库对象的状态信息，这对数据库使用合理的ACCESS PLAN是至关重要的。一般来说，以下几种情况下面，我们需要用runstats来收集统计信息:

　　1. 在给表创建一个index后，我们最好做一次runstat。这个情况也是大家经常忽略的。很多时候大家在给表增加了一个index后，分析执行计划，发现没有变化，觉得很奇怪。其实这个时候，你需要做一次runstats，就可以了。在8.2里面，DB2做了很好的改进，可以避免这个问题，在创建index的时候，可以立即更新你的信息。

　　2. 在对table做了一次reorg后，记得要做一次runstats。因为对表做reorg，会修改表的很多信息，比如高水位等，所以做一次runstats,可以更新统计信息。

　　3. 当你的表里面的数据发生了比较大的变化，一般来说，大约表里面的数据量的10%-20%发生了变化，就应该作一次runstats。这些变化包括删除，修改，插入。对于一些非常大的表，比方在数据仓库的项目里面，某些事实表非常巨大。这个时候，完整的对一个大表作runstats可能花费时间相当大，DB2 8.1里面支持我们对这些大表作抽样，比方说只对20%的数据作runstats，这样的话，一般来说也能保证得到正确的执行计划。当然首先要确保这个表里面的数据最好分布比较均匀。

　　4. 当你在分区(DPF)数据库里面使用了REDISTRIBUTE DATABASE PARTITION GROUP这个命令，那么就需要用runstats来收集新的统计信息。

　　RUNSTATS命令的语法如下:

　　如果表名为DB2INST1.STAFF，表上有索引，则可以用下面的例子完成RUNSTATS命令:

　　db2 runstats on table db2inst1.staff with distribution and detailed indexes all

　　在实际的项目里面，对于变化比较大的表，需要我们定时对数据库做runstats，一般来说runstats和reorg可以结合起来做，首先对表作reorg，然后做runstats，最后REBIND数据库根据最新的统计信息生成合适的统计计划。

　　值得注意的是，如果我们要处理的表数据量是快速变化的，比如在电信移动行业，需要在月末进行处理的汇总表。在不长的时间范围内数据量变化特别大，从而使得RUNSTATS 得到的统计信息不准确，原因是这些统计信息只是某个时间点的信息。您可以用这条语句来把表修改为volatile。

　　alter table table_name volatile cardinality

　　这样优化器将考虑使用索引扫描而不是表扫描。无论统计信息如何，优化器将使用索引扫描而不是使用表扫描。

　　IBM的文档里面还提供了REORGCHK这个命令，可以根据统计公式计算表是否需要重整。

　　比如可以分为对系统表和用户表两部分分别进行REORGCHK:

　　1) 针对系统表进行REORGCHK

　　db2 reorgchk update statistics on table system

　　2) 针对用户表进行REORGCHK

　　db2 reorgchk update statistics on table user

　　需要注意的是，如果数据库中数据量比较大，这些操作一般所需时间比较长，所以尽量安排在数据库比较空闲的时候做。

　　db2 update db cfg using AUTO_MAINT off AUTO_TBL_MAINT off AUTO_RUNSTATS off

　　在DB2 8.2里面数据库可以自动进行统计信息收集，不过这样的动作还是会带来额外的负载，一般情况下面可以关掉，只在我们需要的时候运行就可以了。