● 有三种类型的Latch:parent,child和独立的latches
对应的视图有v$latch_parent、v$latch_children和v$latch
v$latch视图包括了独立的latches、parent latches和children latches的统计信息
● Latch的获取
进程请求latch有两种模式:willing-to-wait和no-wait(立即)。no-wait模式只用于有多个children latch的latch。
如果latch的获取是no-wait模式,所对应的统计信息在IMMEDIATE_GETS和IMMEDIATE_MISSES列。
通常 no-wait模式用于获取有多个children的latch如“redo copy” latch。如果第一次使用no-wait模式获取children latches失败,那下次它还会使用no-wait模式。
当对所有的children latch使用no-wait模式获取失败后,就转而使用willing-to-wait模式。
will-to-wait模式的统计信息对应于GETS和MISSES列。每次willing-to-wait模式的请求latch都会增加GETS的值。
当进程获取到闩锁后,在修改闩锁保护的数据结构之前,进程把恢复信息写到闩锁恢复区。所以当该进程死掉后,PMON进程能够清除它。
如果闩锁不可用,那么进程就在CPU上spins一会儿,然后重新去请求闩锁,spins的时间由_SPIN_COUNT指定,默认值是2000。如果spins了一次就请求到闩锁,进程就在SPIN_GETS和MISSES上加1,否则,进程就在V$SESSION_WAIT视图中发出"latch free"等待事件,然后就sleep。在sleep时间到后,进程醒来重新请求闩锁。没有请求到,就再spins,重新请求,sleep,再醒来...直到获取到闩锁。SLEEP统计信息只有在闩锁GET成功后才更新,平时等待时不更新。
当如果请求的闩锁,被一个死了的进程hold住了,那怎么办?如果进程请求了几次都失败了,它就会通知PMON进程检查hold住这个闩锁的进程。如果持有这个闩锁的进程死了,PMON就清除它并且释放闩锁。
每一个栓锁被分配了一个等级0-13
short-wait latch的被请求者等待时间是按指数增长的,因为如果时间太长,容易引起其它进程的闩锁竟争。
long-wait latch被一些进程长时间的占有, 这些进程平时睡眠,被其它进程叫醒。由WAITERS_WOKEN列指定
SQL> select name, immediate_gets, immediate_misses,
2 gets, misses, sleeps, waiters_woken
3 from v$latch
4 where waiters_woken > 0;
NAME IMMEDIATE_GETS IMMEDIATE_MISSES GETS MISSES SLEEPS WAITERS_WOKEN
---------------------------------------- -------------- ---------------- ---------- ---------- ---------- -------------
messages 0 0 2174072 2 1 1
cache buffers lru chain 892850 0 897836 2 2 2
checkpoint queue latch 45160 0 13341612 1 1 1
redo allocation 0 0 4121269 65 177 177
shared pool 0 0 10664347 4 4 4
library cache 17331 0 21372514 42 54 54
SQL memory manager workarea list latch 0 0 16847904 1 1 1
7 rows selected
大的_SPIN_COUNT的值能够减小MISSES和SLEEPS,cache buffers chains能够修改为较大的值
SQL> select indx, spin, yield, waittime from x$ksllclass;
INDX SPIN YIELD WAITTIME
---------- ---------- ---------- ----------
0 16000 0 1
1 16000 0 1
2 16000 0 1
3 16000 0 1
4 16000 0 1
5 16000 0 1
6 16000 0 1
7 16000 0 1
阅读(1317) | 评论(0) | 转发(0) |