Shared pool的library cache lock/pin及硬解析

最新推荐文章于 2021-01-20 03:51:04 发布

cjh81378066

最新推荐文章于 2021-01-20 03:51:04 发布

阅读量205

点赞数

Shared Pool could be divided in three major parts:
1. Library Cache
2. Dictionary Cache
3. Control Structure

What is shared pool?
Shared pool是SGA中的一部分，由于它是SGA的一部分，这意味着它可以被所有的进程所访问，Shared Pool当中主要包含了2部分：library cache和dictionary cache。
Library cache包含了共享SQL区(shared SQL areas),私有SQL区(private SQLareas,如果配置了共享服务器),PL/SQL存储过程以及包，还有一些控制信息，比如说locks以及library cache handles。
Dictionary cache包含了表，视图的依赖信息，比如表结构，它的用户，Oracle在解析SQL的时候就会频繁的访问dictionary cache。

硬解析使用library cache的流程
shared pool latch-->library cache latch-->Library cache lock-->library cache handle-->Library cache pin-->Library Cache Object

Library Cache结构：hash table-->hash bucket(hash table中的行)-->library cache handle(hash bucket指向的地址就是handle)-->Library Cache Object(Library Cache Object就是一堆library cache heap，library cache handle其实指向的是library cache heap的第一个heap，这个heap记录了指向其他heap的指针信息）

shared pool latch发生在shared pool中的内存空间块(不能简单认为发生在hash table)，library cache latch会引发shared pool latch
library cache latch发生在hash bucket
library cache lock发生在library cache handle( 发生在LIBRARY CACHE PIN后object又重编译或授权操作 )
library cache pin发生在Library Cache Object( 通常是发生在编译PL/SQL,VIEW,TYPES等object时，这些object依赖的表出现了锁，这时编译objects就会出现这个pin )

当 对包，存储过程，函数，视图进行编译的过程中，如果依赖的表发生了DML操作且没有提交，不影响编译的进行

dml不提交，不影响包的的编译

buffer busy wait发生在buffer cache中，并发写才发生

latch： 就像活动锁，可以先锁A箱子，开锁后可以从A箱子上拿走，去锁B箱子
1、一个latch保护多个资源
2、latch本身没有锁定模式。

mutex： 就像固定锁，比如安全门上的锁，无法移动
1、每个资源都有自己的mutex
2、mutex存在锁定模式，S和X。S锁不排斥S锁，但是排斥X锁。X锁排斥所有锁。

use a shared pool latch that serializes access to prevent two processes from trying to inspect or modify the shared pool simultaneously
A main cause of shared pool or library cache latch contention is parsing.
a high hard parse rate is accompanied by latch contention on the shared pool and library cache latches.
使用串行化访问的共享池锁，以防止两个进程尝试同时检查或修改共享池
共享池或库缓存锁定争用的主要原因是解析。
共享池和库缓存锁存器上的锁存争用伴随着高难度的解析速率。

Library Cache Manager
Library cache Manager 可以看做是Heap Manager的客户端，因为library cache manager是根据Heap Manager来分配内存从而存放library cache objects。Library cache Manager控制所有的library cache object，包括package/procedure, cursor, trigger等等

Hash Table and Hash Bucket
Library cache是由一个hash table组成，这个hash table又由hash bucket组成的数组构成，每个hash bucket又是由一些相互指向的library cache handle所组成，library cache object handle就指向具体的library cache object以及一些引用列表。

Library Cache handle
我们对Library cache中所有对象的访问是通过利用library cache handle来实现的，也就是说我们想要访问library cache object，我们必须先找到library cache handle。Library cache handle指向library cache object,它包含了library object的名字，命名空间，时间戳，引用列表，lock对象以及pin对象的列表信息等等。Library cache handle也被library cache用来记录哪个用户在这个这个handle上有lock，或者是哪个用户正在等待获得这个lock。那么这里我们也知道了library cache lock是发生在handle上的。
当一个进程请求library cache object, library cache manager就会应用一个hash 算法，从而得到一个hash 值，根据相应的hash值到相应的hash bucket中去寻找。这里的hash算法原理与buffer cache中快速定位block的原理是一样的。如果library cache object在内存中，那么这个library cache handle就会被找到。有时候，当shared pool不够大，library cache handle会保留在内存中，然而library cache heap由于内存不足被age out，这个时候我们请求的object heap就会被重载。最坏的情况下，library cache handle在内存中没有找到，这个时候就必须分配一个新的library cache handle，同时object heap也会被加载到内存中。

Library Cache Object
Library Cache Object是由一些独立的heap所组成，前面说了Library cache handle指向Library cache Object，其实handle是指向第一个heap,这个heap 我们就称之为heap 0。Heap 0记录了指向其他heap的指针信息。

Library cache lock/pin
Library cache lock/pin是用来控制对library cache object的并发访问的。Lock管理并发，pin管理一致性，lock是针对于library cache handle,而pin是针对于heap。
当我们想要访问某个library cache object，我们首先要获得这个指向这个object的handle的lock，获得这个lock之后我们就需要pin住指向这个object的heap。
当我们对包，存储过程，函数，视图进行编译的时候，Oracle就会在这些对象的handle上面首先获得一个library cache lock，然后再在这些对象的heap上获得pin，这样就能保证在编译的时候其它进程不会来更改这些对象的定义，或者将对象删除。
当 对包，存储过程，函数，视图进行编译的过程中，如果依赖的表发生了DML操作且没有提交，不影响编译的进行
当一个session对SQL语句进行硬解析的时候，这个session就必须获得library cache lock，这样其他session就不能够访问或者更改这个SQL所引用的对象。如果这个等待事件花了很长时间，通常表明共享池太小(由于共享池太小，需要搜索free的chunk，或者将某些可以被移出的object page out，这样要花很长时间)，当然了，也有可能另外的session正在对object进行修改(比如split分区),而当前session需要引用那个table，那么这种情况下我们必须等另外的session进行完毕。

Library Cache lock有3中模式：
l Share(S): 当读取一个library cache object的时候获得
l Exclusive(X): 当创建/修改一个library cache object的时候获得
l Null(N)：用来确保对象依赖性
比如一个进程想要编译某个视图，那么就会获得一个共享锁，如果我们要create/drop/alter某个对象，那么就会获得exclusive lock。Null锁非常特殊，我们在任何可以执行的对象(cursor，function)上面都拥有NULL锁，我们可以随时打破这个NULL锁，当这个NULL锁被打破了,就表示这个对象被更改了，需要从新编译。NULL锁主要的目的就是标记某个对象是否有效。比如一个SQL语句在解析的时候获得了NULL 锁，如果这个SQL的对象一直在共享池中，那么这个NULL锁就会一直存在下去，当这个SQL语句所引用的表被修改之后，这个NULL锁就被打破了，因为修改这个SQL语句的时候会获得Exclusive 锁，
由于NULL锁被打破了，下次执行这个SQL的时候就需要从新编译。

Library Cache pin有2种模式：
l Share(S): 读取object heap
l Exclusive(X)：修改object heap
Library Cache pin没有什么好说的，当某个session想要读取object heap，就需要获得一个共享模式的pin，当某个session想要修改object heap，就需要获得排他的pin。当然了在获得pin之前必须获得lock。

Library cache Latch
Library cache Latch用来控制对library cache object的并发访问。前面已经提到，我们要访问library cache object之前必须获得library cache lock， lock不是一个原子操作(原子操作就是在操作程中不会被打破的操作，很明显这里的lock可以被打破),Oracle为了保护这个lock，引入了library cache latch机制，也就是说在获得library cache lock之前，需要先获得library cache latch，当获得library cache lock之后就释放library cache latch。

存在大量硬解析的系统上面就必然引发library cache latch, library cache lock竞争，比如每秒高达上100个硬解析