Latchesare like short duration locks that protect critical bits of code. LatchFree事件表示该进程在等待一个被其它进程持有的latch。这个事件共有3个参数,意义如下:
- p1 表示latch的地址,一般会用p1raw,也就是p1参数的16进制。我们可以查询v$latch_children和v$latch,通过addr=p1raw来查询
- P2 表示latch号,我们可以通过v$latchname来进行查询该latch的名字
- p3表示 我们已经试图获得该latch的次数
确定latch竞争:
- 一般我们可以通过select * from v$latch where sleep>0 order by sleep desc; 来确定竞争最激烈的latch
- 对于shared_pool latch和library cache latch一般可以通过绑定变量来进行优化
- 对于cache buffer LRU chain,表示buffer cache的使用比较严重;我们要确保db_block_lru_statistics=false
- 对于cache buffer chains latch表示存在单个块的buffer cache竞争。一个cache buffer chains latch管理着一些buffer cache的列表。如果在v$latch_children中存在该latch,则我们可以查询:select * from x$bh where hladd=&child_latch_address;如果查询的记录数在3-10之间,表示说明该latch管理的buffer中有一个块存在严重的竞争;在通过x$bh表中的Tch列(接触的次数),就可以确定是那个buffer存在竞争了。因为,存在竞争的buffer块,其Tch值肯定是很大的
- 我们也可以查询v$latch_misses来查看latch没有申请到的情况select * from v$latch_misses where parent_name=&Latch_addr; 这个视图中的WTR_SLP_COUNT表示等待latch而sleep的时间;SLEEP_COUNT表示等待而sleep的次数
导致latch竞争的几个原因:
- CPU的高利用率 一个进程在得到latch后,由于系统的CPU资源很忙,它得不到CPU来进行处理,从而导致其它进程等待latch,我们可以通过os的信息来查看CPU的高利用率
- 希望所有的进程间歇的持有latch,但是如果一个进程持有latch过长,从而导致这个和谐被打破,导致受这个latch保护的在SGA中的link list过长。例如,在一个充满碎片的shared pool中,标记free memory chunck的list就将很长,导致了latch的竞争。类似的还有hash chain在databuffer、library cache中等。 对于这种类型的latch竞争,我们可以调整_spin_count参数,来让得不到latch的参数直接进入sleep状态。当然,最好的办法还是提高应用效率,减少等待latch的时间
- 如果进程申请latch的次数过多,也会产生latch的竞争。 比如在一个高commit的应用中,我们可能就会存在redo allocation latch的竞争了。
阅读(1103) | 评论(0) | 转发(0) |