说点简单的，我说说共享池里面的两个latch
Shared pool latch用来保护共享池内部结构，在分配和释放共享池时需要获得latch，在老化或释放空间时也需要 latch。Oracle9i之前，共享池内存结构是由单独的Shared pool latch保护，从9i开始，如果服务器有4个以上的cpu且shared_pool_size大于250M,Oracle会动态将共享池分为多个子池，最多可以达到7个sub pool，每个子池有自己的free list，lru list及latch。子池的数量可以通过_kghdsidx_count参数来手动调整。
查看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(*) ———- 11
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 latch和library cache latch争用主要出现在频繁的硬解析上,而过多的硬解析通常又和绑定变量存在关系，因此,共享池的健壮性主要还是取决于应用的设计，而不仅仅是参数的调整。
引自：http://www.taobaodba.com/html/30_latch-shared-library.html
http://www.taobaodba.com/html/57_shared_pool_space_management_3.html Shared Pool空间管理算法的演进(三)