TrackBack: http://antognini.ch/2009/01/execution-plan-hash-value-in-sql-trace-files/
在征得了Christian Antognini的同意后, 木匠准备近乎实时的(near real-time)跟踪报道他的最新研究成果. 附带的好处是极大的增加了我的博客出版频率,完成年初定的每周一篇技术贴的目标.
在我理解有误的地方,欢迎各位DBA同仁给予指正. 木匠没有出钱买断Christian Antognini博客的中文翻译版权, 所以您也可以同时翻译相同的文章, 不过, 请一定指明原文的TrackBack.
我只会讲每篇的主旨和总结. 从2009年一月开始,
第一篇: SQL跟踪文件里面哈希值的变化(Execution Plan Hash Value in SQL Trace Files)
在Oracle 11.1.0.7版本, 在PARSE, EXEC 和FETCH这些行里边, 新出现了一个"plh"属性, 我猜是 Plan Hash 的缩写. plh是为了配合ACS(Adaptive cursor sharing), ACS就是根据不同的绑定变量(binding variable)产生不同的最优执行计划.
参见 http://antognini.ch/2008/12/automatic-evolution-of-sql-plan-baselines/ 第7个木匠的注释.
这里是一个SQL trace file样例,
SELECT count(pad) FROM t WHERE id < :id
PARSE #13:c=0,e=0,p=0,cr=0,cu=0, mis=0,r=0,dep=0,og=1,plh=4270555908
EXEC #13:c=0,e=0,p=0,cr=0,cu=0, mis=1,r=0,dep=0,og=1,plh=2966233522
当变量取值发生变化后,优化器决定选择一个不同的执行计划. 我们看到mis=1和plh=2966233522 出现在EXEC(执行)这一行,而且的plh数值不同于PARSE一行plh的数值 SQL优化器对游标(cursor)做了一个硬解析(hard parse), 然而PARSE部分没有硬解析.
由此改变了我们的传统认识, 不但PARSE部分会hard parse,而且EXEC部分也会hard parse.
去阿拉斯加的邮轮,在维多利亚Ogden Point港停靠.
Tuesday, February 24, 2009
Subscribe to:
Post Comments (Atom)
2 comments:
exec阶段应该是再做一次bind peeking, 比hard parse还是好点吧。
产生一个新的执行计划,就是一个Hard Parse.
ACS(Adaptive cursor sharing)引起的Hard Parse应该比传统的Hard parse少用资源.
Post a Comment