如何在DB2中更新执行计划
2009-12-22 15:00:19 来源:WEB开发网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里面数据库可以自动进行统计信息收集,不过这样的动作还是会带来额外的负载,一般情况下面可以关掉,只在我们需要的时候运行就可以了。
LOAD
Load这个工具是DB2里面一个非常强大的数据迁移工具。一般用作大批量的数据插入。因为Load操作不记日志,所以效率非常好。笔者曾经在RS6000平台上面实现50-60m/s的速度Load数据。在这里我想讨论的是在DB2数据库里面如何用load来影响你的catalog视图的统计信息。
在Load的时候使用statistics选项可以在装入的过程中生成统计数据,这些统计数据可以供优化器确定最有效的执行sql语句的方式。
比如:
对表和索引产生最详细的统计数据:
load from mobile_number.del of del replace into mobile statistics yes with distribution and detailed indexes all
对表和索引都产生简略的统计:
load from mobile_number.del of del replace into mobile statistics yes and indexes all
需要值得注意的时候在DB2 8.2新版本里面,可以这样做:
load from mobile_number.del of del replace into mobile statistics use profile
DB2LOOK
Db2look是DB2一个相当强大的一辅助工具,可以帮助我们从当前数据库里面把数据库结构抽取出来。在数据迁移的很多场合,我们都非常需要这个强大的工具。
在一些场合,特别是开发库迁移到生产库,生产库迁移到开发库的环境中,为了保证SQL执行计划的一致,我们需要用db2look这个工具,利用 db2look 工具提供的抽取数据库对象统计信息的功能,把数据库的统计信息进行迁移。
比如:
1) 在用户环境下提取统计信息:
db2 runstats on table <用户表模式名>.<表名>
db2look -d <用户数据库名> -t <表名> -m -o statis.sql
输出文件中是对用户的 DB2 系统编目表中与该表统计信息相关的各字段值的 update 语句。
db2 -svtf statis.sql
2) 利用用户提供的统计信息更新测试环境下测试表的统计信息:
总结
本文对DB2里面更新执行计划的几个常见的方法,做了一些抛砖引玉的说明。实际工作中的环境,是千差万别的,会有很多的不同。需要强调的是,在DB2数据库里面,基于成本的优化器决定着SQL的执行效率。而正确、及时地收集数据库的统计信息对于让优化器生成正确的执行计划是至关重要的。
更多精彩
赞助商链接