Shared pool latch 和 Library cache latch

Shared pool latch 和 Library cache latch

 

Shared pool latch是用来保护共享池内部结构，在分配和释放共享池时需要获得latch，在aged out或是释放空间时也要latch。9i之前，共享池内存结构是单独的由Shared pool 啦提出保护，从9i开始，如果server有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';

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

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

 

查看Library cache latch 个数

select name,addr, child#, gets, misses from v$latch_children where name = 'library cache'；

 

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

查询version_count高版本的语句

 select substr(sql_text,1,40),version_count
  from v$sqlarea where version_count > 0  order by version_count desc；

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

在记录一个重要的性能视图  select * from v$librarycacle;