SQL跟踪文件里面哈希值的变化 - 启动TOP作者博客翻译

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港停靠.