也许我们会有疑问，假如稳定了执行计划，那还搜集统计信息干吗？这是因为几个原因造成的，首先，现在的执行计划对于未来发生了变化的数据未必就是合适的，存在着当前的执行计划不满足未来数据的变化后的效率，而新的统计信息的情况下所产生的执行计划也并不是全部都合理的。那这个时候，我们可以采用新搜集的统计信息，但是却对新统计信息下不良的执行计划采用ORACLE提供的执行计划稳定性这个能力固定执行计划，这样结合起来我们可以建立满足的高效的数据库运行环境。
我们还需要眼球的一个东西，ORACLE提供的dbms_stats包除了具有搜集统计信息的能力，还具有把数据库中统计信息（statistics）export/import的能力，还具有只搜集统计信息而使得统计信息不应用于数据库的能力（把统计信息搜集到一个特定的表中而不是立即生效），在这个基础上我们就可以把统计信息export出来再import到一个测试环境中，再运行我们的应用，在测试环境中我们观察最新的统计信息会导致哪些执行计划发生变化（DB EXPERT的Plan Version Tracer是模拟不同环境并自动检查不同环境中执行计划变化的工具），是变好了还是变差了。我们可以把变差的这一部分在测试环境中使用hints或者利用工具（SQL EXPERT是在重写SQL这一领域目前最强有力的工具）产生良好的执行计划的SQL，利用这些SQL可以产生OUTLINES,然后在产品数据库应用最新的统计信息的同时移植进这些OUTLINES。
最后说一下我们不得不使用执行计划稳定性能力的场合。我们假定ORACLE的优化器的选择都是准确的，但是优化器选择的基础就是我们的SQL,这些SQL才从根本上决定了运行效率，这是更重要的一个优化的环节。SQL是基础（当然数据库的设计是基础的基础），一个SQL写的好不好，就相当于我们同样是要想去英国，但是我的起点在珠海，你的起点却在西藏的最边缘偏僻的一个地方，那不管你做怎样的最优路线选择，你都不如我在珠海去英国所花费的代价小。
评论加载中…
 |