RUNSTATS到底需不需要？

字数 1263阅读 1854评论 5赞 0

IBM所有的文档都在强调RUNSTATS的重要性，原因很简单，就是为号称业界最强的DB2优化器提供准确的信息以保证其作出正确的决策。如果没有准确的信息，再优秀的指挥官无法作出正确的决策。<div>不过有不少DBA仍坚持认为RUNSTATS可以不做或少做，当然，前提条件是access plan显示优化器选择了我们认为必要的索引！“如果查询计划使用了我们希望看到的索引，那么我们为什么还要经常做RUNSTATS？”。在实际生产环境中我也见到了类似的情况，就是某表在半年前做过一次RUNSTATS，当前记录数为4亿，记录长度为400字节左右，每天新增数据300万条，没有更新和删除，只有查询应用。针对该表的查询耗时0.3秒，使用了索引。由于当前I/O已经成为瓶颈，而且系统基本没有维护窗口，鉴于此情况，相关DBA拒绝针对该表执行RUNSTATS，主要的理由就是执行计划已经使用索引，所以没必要再做RUNSTATS更新信息了，况且做RUNSTATS非常耗时而且势必影响当前应用的性能。</div><div>问题出来了：是否RUNSTATS只是为了通知优化器使用索引这么简单？我持怀疑态度，所以写这篇博文来做个引子，一方面在我进一步发现RUNSTATS的作用后及时记录下来，另一方面希望看到此文的你能分享一下RUNSTATS的经验，最好是实际RUNSTATS前后的效果。</div><div>我举个例子不知道合适不：优化器其实类似导航仪（高级点的那种），A点到B点有两条路，一条近路为R1，另一条稍远的为R2，在将R1和R2的信息更新进导航仪后，我先在要选择“最省时”的路径，那么按照我们的想法肯定是R1了（类似我们想当然的认为优化器选择索引是绝对正确的），事实上开始的时候确是如此，R1由于距离短所以用时较短。不过近来R1由于交通事故频发，所以增加了很多红绿灯，如此一来，R2事实上成为了最省时的路.但是由于增加红绿灯的情况并没有及时更新到导航仪中，所以导航仪仍然提示我们最省时的路是R1.</div><div><br></div><div>RUNSTATS的作用：</div><div>1.减少不必要的排序溢出。</div><div>SORTHEAP指定每个排序能分配的最大内存，实际使用的大小由优化器决定。不准确的统计信息可能使优化器对要使用的排序内存大小估计不准，有可能分配比实际需要少的内存，从而导致不必要的溢出。</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>                                                                                            持续更新中。。。</div><div><br></div>

runstats 数据库

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！