Library Cache Latch和Shared Pool Latch

library cache

我上图中，oracle去5号链上遍历，会把5号链锁住（Library Cache Latch），这样的话如果咱们吧shared_pool设的很大，library cache中缓存的sql/执行计划就会很多，链就会很长，那么遍历的时间就长，锁住链的时间就会很长。


来~~~咱们捋一下sql执行的过程：
说明：我们说的链也可叫bucket

⑴ 一个sql来了，然后oracle一顿内部计算，得到了一个hash_value,然后根据这个值得出到parent cursor的位置（比如就是我上图的5号链/bucket）然后获得Library Cache Latch把这个链给锁住，根据SQL的HASH_VALUE值遍历child cursor，如果找到则为软解析，Server process获得该SQL执行计划，转向第⑷步；如果找不到则执行硬解析，在硬解析的整个过程中，一直持有这个Library Cache Latch锁住对应链。

⑵ 硬解析完成后释放Library Cache Latch，获得Shared Pool Latch，查找并锁定整个free空间，然后找对应大小的chunk链（也叫bucket）找一个可用的chunk，把sql和执行计划写入到对应的chunk中去。

⑶ 释放Shared Pool Latch，重新获得Library Cache Lacth，将这个写了sql和计划的chunk插入到对应链（5号链）中。

⑷ 释放Library Cache Latch，保持Null模式的Library Cache Pin/Lock。

⑸ 开始执行。


当数据库中出现大量硬解析的时候，某一个sql无法得到library cache latch就会开始spin（自旋）,达到spin count后还没得到，就会开始sleep,达到sleep时间后,醒来还再次试图过的library cache latch得不到就再spin再得不到又sleep…依此类推

这样就会造成锁的争用，导致出现latch free等待事件


所以说出现LATCH争用的问题，想用加大shared pool的大小来解决是非常错误的~！！这样不仅不能解决问题，还可能会是问题更加严重，因为你这样不仅没有解决硬解析的问题，反而还会使遍历library cache链的时间变得更长。。。

解决LATCH争用的正确方法是减少sql的硬解析，而不是加大shared pool~！！！

参考：http://oracle.chinaitlab.com/exploiture/814152.html     、    http://www.xifenfei.com/3151.html