latch free等待事件

 

latch free 

latch是一种轻量级的锁。一般来说，latch由三种内存元素组成：pid（进程id），内存地址和内存长度。Latch保证对共享数据结构的排它性访问，以此来保证内存结构的完整性不受到损坏。在多个会话同时修改或者检视(inspect)sga中同一个内存结构时，必须串行化访问以保证sga中数据结构的完整性。 

Latch只是用来保护sga中的内存结构。对数据库中的对象的保护，使用的lock而不是latch。Oracle sga中有许多latch，用来保护sga中各种内存结构不会因为并发访问而损坏。常见的Latch Free等待事件是由于热块 (buffer cache中的latch争用) 及未使用绑定变量(shared pool中的latch争用) 导致的。

最常见的Latch集中于Buffer Cache的竞争和Shared Pool的竞争。和Buffer Cache相关的主要Latch竞争有cache buffers chains和cache buffers lru chain，和Shared Pool相关的主要Latch竞争有Shared Pool Latch和Library Cache Latch等。  Buffer Cache的Latch竞争经常是由于热点块竞争引起；Shared Pool的Latch竞争通常是由于SQL的硬解析引起。

在oracle9i（包括9i）之前，latch free等待事件包括了所有的latch等待，但从oracle10g起，latch被分成不同的种类，并且某些latch表现为独立的等待事件。

如果我们在v$session_wait中发现有latch free等待事件，就意味着，进程在请求一个willing_to_wait模式的latch，在重试了_spin_count次 (默认为2000) 后还是没有获得latch，然后转入睡眠状态了。如果latch争用严重，将会由于不断的spin导致cpu资源紧张，从而增加系统响应时间。

V$system_event视图的total_waits列记录了进程获取willing-to-wait模式latch失败的次数。V$latch的sleeps列记录了进程由于等待某个latch而进入睡眠状态的次数。由于一个进程在_spin_count次尝试请求latch失败后会转入睡眠状态，total_waits列应该等于sleeps列的值的和，如以下sql所示。但是，某些时候，total_waits会比sleeps的和要大，这是因为，只有在进程获得latch后才会更新total_waits的值，而不是每次请求latch失败就更新。

 

Latch的获取   

如果请求latch时，该latch不可用，进程就会在cpu中等待一小段时间(spin)然后重新请求latch。如果latch一直不可用，该过程(spin一段时间然后重新请求)会一直重复。重复的次数由隐含参数_spin_count决定，默认值2000。如果在请求_spin_count次之内获得了latch，就对spin_gets和misses列各加一，否则，进程在v$session_wait中记录latch free等待事件，然后释放cpu，转入睡眠状态。睡眠一定时间后，进程被唤醒并重复上面的过程，一直到获得latch。在成功获得latch后，才会更行sleep列得统计信息。

 

由于进程只有在获得latch后才会停止对latch得请求，如果某个持有latch的进程发生异常，其他请求该latch的进程该怎么办？岂不是要一直等待下去？不会的。当一个进程请求latch失败一定次数后，它会请求pmon进程查看该latch的持有者，如果持有进程异常，pmon就会清理该进程，释放latch。 

 

Latch 争用 

进程在spin的过程中，会一直持有CPU，spin的机制是假设Latch可以被快速释放（正常情况下，Latch的持有时间是微秒级，相对spin机制如果直接采用Sleep方式引起的上下文切换会相当昂贵，所以Oracle针对Latch引入了spin算法），如果其他CPU上的其他进程释放了Latch，SPIN进程就可以立即获得这个Latch。如果系统只有单CPU，那就谈不上SPIN了。另一方面也可以看到，Latch竞争是非常昂贵的，可能导致严重的CPU耗用，所以Latch竞争在任何时候都应该引起充分的重视。经过spin后成功获得Latch的次数被记录在v$latch.spin_gets字段。通过下图来说明一下Latch竞争的情况。

 

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/35489/viewspace-697396/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/35489/viewspace-697396/