我要投搞

标签云

收藏小站

爱尚经典语录、名言、句子、散文、日志、唯美图片

当前位置:2019跑狗图高清彩图 > 争用 >

转载)处理SQL解析失败导致share pool 的争用

归档日期:08-15       文本归类:争用      文章编辑:爱尚语录

  该系统为OLAPOLTP混合系统,平时为交易型数据库。每个网点实时数据上传,月底会有统计类报表产生。

  硬解析比如一个新执行的SQL没有在共享池中,那么就要经历一个硬解析的过程,关于过程这里就不在多讲

  还有就是查询一些底层的视图比如x$ksmsp在某些版本下高并发的系统中直接查询这些视图会出现大量的latch竞争

  从AWRSleep来看sharedpool排在了第一位。从调用的函数来看都是发生在硬解析这个过程中。

  当前现在也可以排除人为查询底层视图导致的latch竞争因为没有看到相关函数出现,插播一个类似的案例。

  有的时候分析问题会陷入一些误区,比如一个数据库出现大量的latch竞争导致会话飙升然后把process撑满,从timemode里面来看的线%都是花费在了连接上面,那么到底是大量不正常的连接(比如连接泄漏)导致了数据库出现竞争呢,还是数据库出现问题导致会话不能等了然后不停的重连导致了问题呢。

  从这个库这个时间点的timemode可以发现75%的dbtime都是花费在了解析上面,这也是没有问题的因为这个时间点数据库竞争就出现在解析上面,但是为什么其中有38%的dbtime发生在解析失败上面呢,也就是总共解析的一般时间都是错误的解析。硬解析只有5%左右。

  数据库正常时间点硬解析也只有不到5%左右,也就是硬解析没有大的变化,但是解析失败确认翻了几倍。是什么原因导致这么多的解析失败呢?另外解析失败的SQL是否会导致大量latch竞争?解析失败的SQL是否会在共享池中存储?怎么查询到解析失败的SQL?

  很多时候我们会有这样一个误区,既然语法错误或者对象不存在应该在语法语义检查这个步骤就挂了怎么还好存在共享吃里面呢?带着这个几个问题我们做几个简单的测试。

  那么怎么证明就是解析失败的SQL存在共享池中并且在解析的时候持有librarycachelatch呢?

  Librarycache是sharedpool中的一块内存区域,主要作用就是缓存执行过的SQL语句所对应的执行计划信息等信息。当同样的SQL再次执行时候可以直接利用已经缓存的相关对象不需要再从头解析。

  当sql执行时候,首先会对sql文本进行hash运算然后根据hash值去相关hashbucket中遍历,如果找到了就直接用该sql缓存的执行计划等,如果找不到则从头解析,并把解析后执行计划等缓存在hashbucket中。

  我们知道SQL语句必须至少是一个父游标一个子游标存在的,当然生产中很多情况下都是一父多子的情况。

  父游标与子游标结构是一样的,区别在于sql文本存储在父游标对应的对象句柄中,而sql的执行计划等信息存储在子游标对应的库缓存对象句柄heap6中。另外父游标的heap0中存储着子游标的句柄地址。如果解析错误的SQL在共享池中存储的话那么必然要产生一个父游标然后父游标里面存储的有SQL文本之类的信息,但是子游标的?既然解析失败那么就没有产生执行计划。

  父游标句柄对地址可以在x$kglob视图中查询到,KGLHDPAR=KGLHDADR的记录为父游标

  关于解析错误的SQL是否需要获取latch其实从上面的测试已经证明了还是要获取sharedpool的latch的因为生成了父游标。

  当然最后该问题定位到了相关解析失败的SQL,该SQL主要是在月底某一模块批量跑的时候大量的执行,最后修改应用程序代码解决了问题。

  通过这个简单的案例可以看到不规范的开发习惯给数据库带了严重的性能影响。像类似这种解析出错的SQL在很多客户核心系统中比比皆是但是由于种种原因不能及时去除类似的SQL最终将带来灾难性的影响。

本文链接:http://textandcandy.com/zhengyong/446.html