11g执行计划管理SPM(SQL Plan Management)的研究(一)

其实很早就想要研究这个11g topic,但是“鄙人”一直很懒,研究了一半之后被其他事情“蒙蔽”住了双眼,这几天闲着没事偶尔翻出来了。不想把这件伟大的事业“太监”下去了。所以决定把这一块继续写下去。 首先学习一个新东西,我们会了解它的概念(concept),但是官方的概念是比较枯燥的,那么我们换种思维方式,先抛出几个问题,然后从回答问题中穿插概念(concept)
我这篇文章的问题有三个:1.什么是SPM? 2.SPM为什么会出现? 3.它是如何工作的?
1.什么是SPM?
SPM就是SQL PLAN MANAGMENT(SQL执行计划管理)的简称,SPM提供SQL执行计划的稳定性。它能够帮我们把执行计划完整的保存下来。以便于我们在schema出现变化、数据量发生变化等情况下,保证执行计划的一致性。它就和outLine的作用一样,不同的是它比outline更加复杂。在11.1以后,Oracle已经不再赞成我们使用outline了。它们两个同时出现在一起的情况下,outline会优先级更高。同时SPM的底层实现原理也是采用的是outline技术。
2.SPM为什么会出现?
SPM说白了就是固定执行计划的东西,为什么会产生它?那是因为执行计划发生改变,往往会引发性能问题,严重的时候导致数据库资源耗尽。我相信很多DBA都遇到过这种问题。那么引起执行计划发生改变的原因有哪些呢?
1.优化器统计信息发生改变(Table和Column的统计信息、索引的统计信息);
2.系统统计信息和系统设置(IO性能和利用率、CPU性能和利用率);
3.和优化器相关的参数发生改变;
4.Schema和元数据定义发生改变;
5.数据库升级,比如从10g升级到11g;
6.自适应游标(Adaptive cursor sharing),基数反馈(cardinality feedback);
3.它是如何工作的?
说的直白一点,我们首要先把执行计划“捕捉”到baseline里面。制作做成基线。这些第一次捕捉进去的计划在baseline里面都是被接受(accecpted)的。我们可以通过DBA_SQL_PLAN_BASELINES查看。当语句再一次以解析运行,就需要去Repository库里面找,如果存在或者执行计划和基线相同,则当前执行计划将被使用,如果和基线不一样,就会先把这份计划保存起来,然后Repository库去中找到cost最低的。然后这条PLAN就作为Non-Accept的PLAN存放到SQL Plan History里面。这条PLAN要经过验证(Verify)之后,才会进化成Accecped的计划。在下一次运行的时候才有可能会被使用到。
SPM的三大“招数”。capture、selection、evolution。
SQL plan baseline capture
SQL plan baseline selection
SQL plan baseline evolution
结论
所以我们可以看到,SPM提供了一种稳定性的措施。帮助我们能够很好的控制执行计划改变引起的性能问题,这一点类似于outline和sql profile,同时它又具备了前两者不具备的灵活性,它保障我们计划只会往好的方向发展。而不会一成不变。这种灵活性和优化器自身的灵活性比起来又差了很多。例如:本来一个语句,优化器发现走索引比走全表扫描快,但是它还是走全表扫描,因为新生成的计划需要Verify后才能被Accecped.

分享到: 更多

Post a Comment

Your email is never published nor shared. Required fields are marked *