木匠的微型博客 Charlie Twitter

    follow me on Twitter

    Tuesday, February 24, 2009

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

    2 comments:

    gengmao said...

    exec阶段应该是再做一次bind peeking, 比hard parse还是好点吧。

    Unknown said...

    产生一个新的执行计划,就是一个Hard Parse.

    ACS(Adaptive cursor sharing)引起的Hard Parse应该比传统的Hard parse少用资源.