Latches are 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的高利用率
• oracle希望所有的进程间歇的持有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的竞争了。