DB2常用工具：RUNSTATS、REORG

RUNSTATS使用建议：
1） 当表的数据量发生了很大的变化，如通过load加载了大量数据，或REORG后，或新增了索引等，建议为相应的对象收集RUNSTATS信息，为优化器提供最准确的依据。
2） 为减小对应用的影响，尽可能地在空闲时执行RUNSTATS。
3） 当表很大，或运维窗口很小，或表数据频繁变动时，可考虑在某些关键字段执行RUNSTATS，而不是在所有字段。
4） 当表很大、统计的时间很长时，可考虑采取抽样统计。
5） 为提高可用性，推荐使用allow write access选项，但使用该选项时不能有太多增删改操作，否则可能会造成数据和索引统计不一致。
6） 系统表也需要经常做RUNSTATS。
7） 为减少统计信息不一致的情况，考虑在表和索引上同时进行统计信息收集。
8） 当执行完RUNSTATS后，要发出commit命令以释放锁，对于静态语句，还需要对package重新绑定，以便生成新的访问计划。

REORG使用建议
1） 如果表上有大量的增删改操作，产生碎片的几率会很大，建议重组。
2） 当Reorgchk命令提示（如果统计结果F1，F2或F3标记为*，则该表需要重组，如果索引统计结果F4-F8有*标记，则需要对索引重组）需要重组时，建议重组。
3） 创建表压缩时，通过Reorg建立压缩字典表，并进行表压缩。
4） 对于离线重组，需要确保有足够的表空间存取影子拷贝，否则重组会失败。
5） 对于在线重组，由于每次数据迁移都需要记录日志，因此必须确保有足够的日志空间。同时，需要确保util_heap_sz数据库参数的值足够大。
6） 在同一时刻，同一张表上只能有一个重组，但只要资源允许，可以同时执行几个表重组。
7） 对于普通表来说，当执行在线索引重组时，必须为一张表的所有索引执行，而无法选择为某个索引执行。
8） 对系统表也要经常做Reorg。
9） 重组最好不要和其他工具一起执行，因为可能会产生锁竞争导致回滚。

注：参考《DB2数据库管理最佳实践》第10章