当前位置:Gxlcms > mysql > latch:librarycache等待(只存在于9i,10g)

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

时间:2021-07-01 10:21:17 帮助过:33人阅读

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值->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+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大的最小质数值,可以被 _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以上比较好。设定了该值后Oracle将执行三次以上的SQL Cursor信息保存到PGA内,信息包括SQL文本与对于库高速缓存的指针值。用户一旦提交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)

人气教程排行