通过案例学调优之--和 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 里是否存
在该 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,也就会重新硬解析一次。
|
相关推荐
|