Shared pool和library cache latch -- Oracle -- IT技术博客大学习 -- 共学习共进步！

您现在的位置：首页 --> Oracle --> Shared pool和library cache latch

Shared pool和library cache latch

浏览:3050次出处信息

Shared pool latch用来保护共享池内部结构，在分配和释放共享池时需要获得latch，在老化或释放空间时也需要 latch。Oracle9i之前，共享池内存结构是由单独的Shared pool latch保护，从9i开始，如果服务器有4个以上的cpu且shared_pool_size大于250M,Oracle会动态将共享池分为多个子池，最多可以达到7个sub pool。子池的数量也可以通过_kghdsidx_count参数来手动调整，每个子池有自己的结构，lru列表和shared pool latch。

查看Shared pool latch个数

SQL>select a.ksppinm,b.ksppstvl from x$ksppi a,x$ksppsv b where a.indx=b.indx and a.ksppinm=\'_kghdsidx_count\';

KSPPINM KSPPSTVL

----------------------------

_kghdsidx_count 2

SQL> select name,addr, child#, gets, misses from v$latch_children where name = \'shared pool\';

NAME ADDR CHILD# GETS MISSES

-------------------------- ---------------- ---------- ---------- -

shared pool 070000000006D8E0 7 0 0

shared pool 070000000006D7E8 6 0 0

shared pool 070000000006D6F0 5 0 0

shared pool 070000000006D5F8 4 0 0

shared pool 070000000006D500 3 0 0

shared pool 070000000006D408 2 3477094 796

shared pool 070000000006D310 1 3599730 387

7 rows selected.

Oracle9i之前，过大的共享池会增加Shared pool latch的争用，因为共享池中的空闲内存被分类，并保存在大量的存储桶或空闲列表上，较大的共享池趋向于较长的空闲列表，进程在获得共享池内存池之前，需要持有latch扫描很长的空闲列表，这在高度并发的系统中可能会生产 latch争用，特别是一些不使用绑定变量的系统。

Library cache latch用来保护库高速缓存内部结构，Oracle进程在库高速缓存中修改，检查，锁定，加载或执行对象时都需要先获得latch，latch的数量通常大于cpu_count的最小质数。可以通过_kgl_latch_count参数进行手动更改。

查看Library cache latch的个数

SQL> select count(*)from v$latch_children where name=\'library cache\';

COUNT(*)

----------

Library cache latch争用通常出现在具有高版本数的sql语句中，这些sql的表面字义是相同的如select * from test，但可能属于不同的底层如schema，因为这些sql具有相同的散列值和不同的版本，oracle需要去比较该语句和现有版本，这期间需要一直持有latch的，这可能会造成其他进程无法获得 latch。

查看高版本的sql语句：

select substr(sql_text,1,40),version_count

2 from v$sqlarea where version_count > 10 order by version_count desc;

SUBSTR(SQL_TEXT,1,40) VERSION_COUNT

-------------------------------------

insert into AUCTION_SYSTEMLOG ( 172

update smon_scn_time set orig_thread=0, 90

总的来说，shared pool和library cache争用主要出现在频繁的硬解析上,而过多的硬解析通常又和绑定变量存在关系，说了半天还是回到应用上,共享池的健壮性主要还是取决于应用的设计，而不不仅仅是参数的调整。