模拟软解析引发的latch: library cache

  对于library cache 锁存器,之前在对shared pool锁存器说明时,进行了一定的讨论。为了寻找空闲Chunk,通过shared pool锁存器，实现保护

扫描空闲列和分配适当Chunk;为了执行SQL。通过library cache锁存器,保护检索并管理库高速缓冲区的所有工作。

library cache 锁存器拥有比CPU count值大的最小质数值相同数量的子存储器（child latch)


SQL> show parameter cpu_count;

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
cpu_count			     integer	 4
SQL> select rownum,name,gets from v$latch_children where name = 'library cache';

    ROWNUM NAME 						    GETS
---------- -------------------------------------------------- ----------
	 1 library cache					    8987
	 2 library cache					   10779
	 3 library cache					   12706
	 4 library cache					   14812
	 5 library cache					   15661

在获得library cache锁存器过程中,若发生争用,则等待latch:library cache事件。library cache 锁存器争用主要在如下情况下发生:

Hard Parsing 或Soft Parsing 过多时

Version count高时

SGA区域发生Page out时

5.2.1 Hard Parsing 或Soft Parsing 过多时

 Shared pool 锁存器争用主要是因Hard Parsing引起的空闲列检查,与此相同,library cache锁存器争用的最重要原因也是Hard Parsing.若Hard Parsing过多发生,

就因如下原因引发了library cache 锁存器争用。


第一.因为检索库高速缓冲区的次数增加,相应地拥有library cache 锁存期的时间和次数会增加

第二.hard parsing 时,不仅需要对库高速缓冲区的查询,还需要进行额外的Chunk分配,因此相应地延长了拥有library cache 锁存器的时间。


对于Hard Parsing 和library cache 锁存器,shared pool锁存器之间相关关系及性能改善方案早已进行过充分讨论,

因此不会对Hard Parsing进行阐述。

从某种角度看,library cache 锁存器争用是比shared pool锁存器争用更严重的问题。

其理由是library cache锁存器争用Soft Parsing（合理使用Bind变量时)也会发生,Soft Parsing虽然比Hard Parsing费用低,但也不能避免语法和定义检查。

在这些过程中,检查库高速缓冲区期间必须获得library cache锁存器。因此在许多会话同时执行soft parsing时,也会发生library cache锁存器争用引发的性能下降现象。


测试过多的Soft Parsing引起的library cache 锁存器争用,测试方案如下:

开多个窗口执行如下SQL:

session_cached_cursors：每个会话最多可以缓存多少个关闭掉的cursor,

指定了cache的session cursors数量,同样的SQL语句重复解析导致session cursor移动到session cursor cache

随后 parse calls可以在cache中找到cursor，没有必要再次打开游标。

SQL> alter session set session_cached_cursors=0;
begin
   for i in  1 .. 100000000
    loop
    execute immediate 'select 1 from  test test';
    end loop;
    end;                                                                                p1     p2      p3
1	03-7月 -14 04.08.30.385 下午	1621	latch: library cache	2220128512	215	0	0	-1	0	0
2	03-7月 -14 04.08.30.385 下午	1629	latch: library cache	2220128512	215	0	0	-1	0	0
3	03-7月 -14 04.08.30.385 下午	1630	latch: library cache	2220128512	215	0	0	-1	0	0
4	03-7月 -14 04.08.03.355 下午	1621	latch: library cache	2220128512	215	0	0	-1	0	0
5	03-7月 -14 04.08.03.355 下午	1630	latch: library cache	2220128512	215	0	0	-1	0	0

---由测试可知,基本上没有hard parsing，只执行soft parsing时,也会广泛出现latc:library cache等待。


利用SESSION_CACHED_CURSORS参数。如果此值已被设定,Oracle就将已执行三次以上的SQL CURSOR的信息保存到PGA内,所保存的信息时SQL文本和对于库高速缓冲区的指针值。

用户请求执行SQL时,Oracle将确认PGA上是否存在其信息,相应的拥有library cache 锁存器的时间也会随之减少