通过案例学调优之--和 SHARED POOL 相关的主要 Latch

通过案例学调优之--和 SHARED POOL 相关的主要 Latch
3.1、和
SHARED POOL 相关的主要
Latch 有:
Latch: shared pool
Latch: library cache
我们知道 Oracle
通过 SHARED POOL
来实现 SQL
共享,减少硬解析等。而 SQL
的相关信息,如:SQL
语句文本,SQL
执行计划等都存放在 SHARED POOL
的 Library Cache
部分。

3.2、其中
Library Cache 的结构如下图:





      可以看到其结构和
BUFFER CACHE 类似,为了能够在
Library Cache 中快速的查找到对应的
SQL,也是通过将不同的
SQL 语句通过
HASH 函数
HASH 后放置到对应
Hash Bucket 来保存的。 

下面看看图中***的块(右上角标注着:Object Handle):
1) 这个块也就是所谓的
Library Cache Object Handle,这个
Handle 描述
Library Cache 中对象的一些属性,如名称(Name),所属的命名空间(Namespace)、标记(Flags)、指向对象所处的内存地址的指针(Heap
0)等。对应 SQL
来说,这个可以算是父游标。

2)
Heap 0 用来存放与对象有直接关系的一些信息,比如对象类型、对象相关的表、实际的执行计划等。

3) 同一个
Hash Bucket 中的
Object Handle 相互链接形成一条
Chain。

关于 Library Cache
更详细的可以查阅 Julian Dyke
的 Library Cache Internals.ppt。

Eygle
网站上也有一张简洁的图:





3.3下面先看SQL的的整个执行过程来,然后再看看执行过程中是怎么用到SHARED
POOL的相关 Latch。

1)  当客户端执行一条
SQL,这时候
Oracle 首先将
SQL 文本转换成
ASCII 值,然后根据
HASH函数计算该
SQL 对应的
Hash Value。

2)  根据得到的
Hash Value 到
Library Cache 中查找对应的
Bucket,然后查找
Bucket <
20000
span style="font-family:SimSun;font-size:10pt;">里是否存

在该
SQL?

(Y) 如果存在,则接下来查找对应的子游标,这个时候将一直持有
Library CacheLatch,直到找到对应的执行计划。然后释放
Latch。(软解析)
(N) 如果不存在,就要去
SHARE POOL 里面获得可用空间,来生生成对应的
LibraryCache 对象。这个时候就要获得
Shared Pool Latch
在 SHARE POOL
的 Free Lis(SHRAEPOOL
通过 Free List
管理 Free Chunk)查找可用的空间,之后释放
Shared Pool Latch。接下来就开始进行硬解析过程,将执行解析后的执行计划等信息记录到
LibraryCache 中,这个整个过程消耗大量的
CPU,同时将一直持有
Library Cache Latch,一直到硬解析结束。(硬解析)

3)  根据获得的执行计划,开始执行
SQL,如:到
BUFFER CACHE 查询数据等。

3.4
整个逻辑如下如:





3.5
当出现Latch竞争严重的时候:
3.5.1如果同时出现大量的
Share Pool Latch
和 Library Cache Latch
的话,根据上面的逻辑那说明数据库中存在大量的硬解析,这个时候就要查找那些
SQL 没有绑定变量。
3.5.2如果只是出现大量的
Library Cache Latch
的话,那么可能有两种情况:
1) 当持有
Library Cache Latch
查找 Bucket
对应的 Chain
时候,发现存在高 Version
的 SQL,这个时候就要扫描这些对应的子游标,整个过程将一直持有
Latch,导致其他会话获取不到
Latch 进行操作。

2) 大量的并发请求,而且不能实现
SQL 一次
Parse Call 多次
Execution。 

案例分析：

3.6
测试模拟为硬解析和 SQL
的 Version Count
高的情况。
3.6.1Oracle 10g 有方法可以让
SQL 产生很多的子游标,必须具备下面几种的条件:

1)cursor_sharing = similar

2)收集了列上的 histogram

3)SQL
中使用到了此列作为条件,并且条件是“等于”
4)这个
SQL 是没有绑定变量的

这时候,Oracle 会认为每条
SQL 的
literal 变量都是
unsafe 的,因此就不重用以前的
cursor而新产生一个
version,也就会重新硬解析一次。

     可以看到 SQL
的 Version_Count
很高,而且 V$SQL
视图里面也能查到对应的子游标。

案例分析：

模拟高并发下,对
Version Count 高
SQL 查询:

session 1：

可以查看到，在sql运行期间有大量的Library Cache latch（mutex）的竞争。

本文出自 “天涯客的blog” 博客，请务必保留此出处http://tiany.blog.51cto.com/513694/1575964