读书笔记-高级owi与oracle性能调整-latch和lock

锁存器和锁存在的理由就是保护在同时工作中所使用的Oracle资源.若想解决锁存器和锁上发生的性能问题,不仅需要掌握锁存器和锁的工作方式,而且对具体资源等级上使用的锁存器和锁,也需要有比较详细的知识.
Oracle为了降低与锁存器相关工作的负荷,不保障锁存器获得次序.
锁存器所保护的资源就是SGA.访问SGA的所有进程,在获得相应管辖的锁存器后,方可访问.
特定内存区域使用多个子锁存器.相反,部份内存区域为了同步化,只使用一个锁存器.子锁存器的使用不只取决于内存区域的大小,还主要取决于内存结构和算法 应通过多少锁存器进行管理.父锁存器和独立锁存器,可以通过v$latch_parent视图观察;子锁存器,则可以通过 v$latch_children视图观察.随着oracle版本的不断更新,独产锁存器变为父,子锁存器的情况较多,子锁存器的数量也不断在更新.锁自 身也存在于SGA共享池区域的内存结构体,通过锁存器受到保护.
在拥有一个以上锁存器的状态下,还想获得其它锁存器的进程,就必须获得比最后一次获得的锁存器更高等级的锁存器.如果因某种原因,要获得比当前拥有的锁存器等级低或相同的锁存器时,会以NO-wait模式获取,以防止死锁引起的无限等待.
锁存器基本上使用Exclusive模式.因此,第一瞬间只能有一个进程拥有锁存器.但是对特定锁存器也可以使用共享模式.
willing-to-wait模式下的锁存器获得过程中失败,则循环适当的次数,并试图重新获取锁存器,它的循环次数与_spin_count(缺省值 是2000)参数值相同.最初的锁存器获得失败后不会马上睡眠,而是自旋(spin),其理由是:第一,因为期待其它的进程在很短时间内释放锁存器;第 二,因为如果陷入睡眠状态,在OS层面上会发生Context switching,这部份的资源消耗比起使用较少的CPU进行自旋更多.
获得锁存器后,欲修改共享内存的进程,在修改前将要修改的内容记录到锁存器恢复区(altch recovery area).如果持有锁存器的进程结束,则PMON调用对各个锁存器所对应的清除功能.各锁存器的清除功能是利用锁存器恢复区所记录的信息,将共享内存恢 复原状,此项工作结束后PMON将释放锁存器.为获得锁存器而等待的进程在尝试4次失败后,向PMON发出检查持有相应锁存器的进程是否存在的请求.
v$latch字段说明:
gets:willing-to-wait模式下睡眠之前的锁存器请求次数.
misses:willing-to-wait模式下睡眠之前的锁存器的获得失败次数.
spin_gets:willing-to-wait模式下睡眠之前的自旋阶段的获得成功次数.
sleeps:willing-to-wait模式下睡眠次数.
immediate_gets:no-wait模式下锁存器获得成功次数.
immediate_misses:no-wait模式下锁存器获得失败次数.
wait_time:为获得锁存器而等待的时间(ms)
如果在willing-to-wait模式下的misses/gets值和no-wait模式下的immediate_misses/(immediate_gets+
immediate_misses)值在1%以上,也可以判断发生了锁存器争用.或者用wait_time,当等待时间大于CPU时间一定值时,也可以判断为发生了锁存器争用.通过等待事件的等待时间也可以获得同样的信息.
锁的名称和资源名称是相同的.例如TM锁保护TM(table)资源.
锁的模式:
0:none
1:null(N)
2:sub-shared(ss)或row-shared(rs)
3:sub-exclusive(sx)或row-exclusive(rx)
4:shared(s)
5:shared-sub-exclusive(ssx)或shared-row-exclusive(srx)
6:exclusive(x)

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

转载于:http://blog.itpub.net/28539951/viewspace-1264946/