latch:librarycache等待（只存在于9i,10g)

latch: library cache等待（只存在于9i,10g) SQL-ASCII-Hash_value-hash bucket，然后申请保护该bucket的library cache latch（3-67个latch保护成千上万个hash bucket)，这个latch是为了保护会话在检索bucket对应的hash chain的过程中，hash chain结构不被改

latch: library cache等待（只存在于9i,10g) SQL->ASCII->Hash_value&＃20540;->hash bucket，然后申请保护该bucket的library cache latch（3-67个latch保护成千上万个hash bucket)，这个latch是为了保护会话在检索bucket对应的hash chain的过程中，hash chain结构不被改变。 在chain上会挂着一串父cursor头的指针，每检索到一个指针，就到所指向的内存区，去看这个父cursor是否符合（sql文本是否相同），chain发现相应父cursor后，再寻觅里面的子cursor，找到可重复利用的综合型计划等信息，就会释放latch，这个过程叫软解析。 假如没有找到可重复利用的cursor,就要hard parsing了。先释放library cache latch，获得shared pool latch锁存器，检索并分配可用的chunk，然后释放shared pool latch，这些chunk就算是进入library cache中了。然后查询优化器生成执行计划，并存到相应chunk上。再次获得library cache latch，然后将这些chunk挂到hash chain上。
若在library cache latch获得发生争用，就须等待latch: library cache事件。然后SQL才开始执行，此时转入library cache pin&＃43;lock(null模式) select value from v$parameter where name='cpu_count'; --32个cpu select rownum,name,gets from v$latch_children where name like '%library%'; --37个library cache 子锁存器，一般认为子锁存器数量是比cpu_count大的最小质数&＃20540;,可以被 _KGL_LATCH_COUNT 参数控制 原因： 1.hard parsing或soft parsing过多，硬解析时除了检索library cache的hash chain费时间，还得花时间额外分配chunk。就算是仅有软解析，也会发生争用，因为其还有语法检查语义检查、库高速缓冲区检索这些过程，在这些过程中也得先获得library cache latch。这个等待伴随shared pool latch等待就是硬解析过多（因为要分配chunk），没有后者就应该仅是软解释过多。
2.High Versions Count，子游标过多，v$sqlarea的version_count字段显示有多少个子游标，或者v$sql的child_number字段，从0开始算的。bucket->hash chain->检索到这个文本对应的cursor，还得检索这个父cursor下面的几个子cursor，例如不同用户发出的相同sql就会有一样的父cursor，此时获得library cache latch的时间会延长。 High version counts can easily cause high contention for library cache latches. A process parsing a SQL statement with many versions (children cursors) will need to scan through all these children while holding on to a library cache latch. This means that other processes needing the same latch will have to wait and can lead to significant database-wide performance degradation. 3.SGA区发生OS层面的page out，
解决： 1.要使用绑定变量减少硬解析，软解释最好也设法减少，例如应用上用缓存等。 2.session_cached_cursors参数默认为0，设为50以上比较好。设定了该&＃20540;后Oracle将执行三次以上的SQL Cursor信息保存到PGA内，信息包括SQL文本与对于库高速缓存的指针&＃20540;。用户一旦提交SQL，首先看PGA，存在的话直接跳到library cache的cursor那。所以这个参数是softer soft parse，软解析的软解析。因为这个参数针对会话，所以维持会话的连接性才能有效，例如配置中间件连接池。itpub的vage说，软软解析时，10.2.0.1中有，10.2.0.2--10.2.0.4没有，到10.2.0.5又有了。到11G又没了，搞不明白Oracle是咋想的。 3.HP_UX,AIX用LOCK_SGA参数设为true(默认false)，SunOS用_USE_ISM参数设为true（默认true)。
后续： 11g，这个等待事件library cache: mutex X就是早期的latch: library cache等待。10g后很多latch用mutex代替。_kks_use_mutex_pin=false可以禁止mutex)