sp; 7 2 4 18 100 68 18 ---
DB2ADMIN XIE4T_CKD 4893 6 2 18 6 90 80 18 ---
SYSIBM SQL010510174815750 4893 49 2 28 4893 81 87 2 ---
--------------------------------------------------------------------------------
CLUSTERRATIO 或正常化的 CLUSTERFACTOR (F4) 将指示索引需要
REORG,该索引与基表不在相同的序列中。
当在表中定义了多个索引时,一个或多个索引可能被标记为需要 REORG。 指定 REORG
顺序的最重要索引。
至此,试验完成。接下来比较一下运行统计和重组前后运行成本,如下图:
运行重组统计前
运行重组统计后
对比运行统计前后的SQL语句成本可以看出由运行前的4469变成了运行后的1572,运行成本是原来的三分之一多。然后再运行程序发现响应速度比以前有大幅度的提高,到此这个棘手的问题算是解决了(当然这是治标不治本,要从根本改变就应该从SQL语句本身入手优化它的性能)。同时我对于“采用导入的方法将此表数据装载进来却没有发现上述现象”这个问题也找到了答案,那就是——在IMPORT过程中由于导入目标表示新表,IMPORT工具将会用类似运行统计的方式将数据均匀填充到叶面当中,因此速度也会加快。这个问题说明对于在数据库中那些经常发生变动的表,定期进行运行统计是对数据库性能提高是有帮助的。
【附录:一些其他的背景知识】
对 reorgchk 所使用的度量的考虑因素包括:(当查看 reorgchk 工具的输出时,找到用于表的 F1、F2 和 F3 这几列,以及用于索引的 F4、F5、F6、F7 和 F8 这几列。如果这些列中的任何一列有星号 (*),则说明当前的表和/或索引超出了阈值。)
F1: 属于溢出记录的行所占的百分比。当这个百分比大于 5% 时,在输出的 F1 列中将有一个星号 (*)。
F2: 数据页中使用了的空间所占的百分比。当这个百分比小于 70% 时,在输出的 F2 列上将有一个星号 (*)。
F3: 其中含有包含某些记录的数据的页所占的百分比。当这个百分比小于 80% 时,在输出的 F3 列上将有一个星号 (*)。
F4: 群集率,即表中与索引具有相同顺序的行所占的百分比。当这个百分比小于 80% 时,那么在输出的 F4 列上将有一个星号 (*)。
F5: 在每个索引页上用于索引键的空间所占的百分比。当这个百分比小于 50% 时,在输出的 F5 列上将有一个星号 (*)。
F6: 可以存储在每个索引级的键的数目。当这个数字小于 100 时,在输出的 F6 列上将有一个星号 (*)。
F7: 在一个页中被标记为 deleted 的记录 ID(键)所占的百分比。当这个百分比大于 20% 时,在输出的 F7 列上将有一个星号 (*)。
F8: 索引中空叶子页所占的百分比。当这个百分比大于 20% 时,在输出的 F8 列上将有一个星号 (*)。
对所有表运行 reorgchk 工具,并确保您正在使用当前统计信息,可使用命令:
reorgchk update statistics on table user
可以使用如下语句来检查任何没有统计信息的表:
select tabname from syscat.tables where stats_time is null
可以使用如下语句来检查任何没有统计信息的索引:
select indname from syscat.indexes where stats_time is null
可以使用如下语句来查找具有时间超过 30 天的统计信息的表和索引:
select tabname from syscat.tables
where stats_time < current timestamp - 30 days
select indname from syscat.indexes
where stats_time < current timestamp - 30 days
注意: 在使用 runstats 命令的时候,必须指定表所在的模式。