1. 首页
  2. IT资讯

Oracle Shared Pool机制之——Latches, Locks, Pins and Mutexes

1.  Lathes                                                  

  如上场景中,Latches将派上用场。Latches是保护系统全局区共享数据结构的简单、低级的串行机制。Latches消除了多进程同时修改共享内存时面临的冲突问题。当服务器或后台进程操作或访问这些共享数据结构时,将会在很短时间内获取Latches。

 

当Latch被长久持有或Latch需求太高时,就会产生Latch冲突。影响Latch

1)  覆盖整个库缓冲的Latches数。如果Latches数较多,那么,每个Latch保护的哈希桶数就会更少,当你需要搜索某个哈希桶链表时与其他使用相同Latch的用户发生冲突的几率就会少;另一方面,如果系统中有更多的Latches,那么,系统将会有更多的维护、报告或清理任务要做。

直到Oracle 10g版本,覆盖库缓冲的Latches数都非常少。该数目依赖于系统上的CPUs数,应该是与cpu_count参数值相当在,直至最大达到67个Latches。这个数目出奇的小,以至于,即使在系统上运行少量而频繁执行的不通过语句,即使存取不同的哈希桶,但可能因为获取相同Latch而发生Latches冲突。

一旦发现某个对象,我们可以给该对象附加一个KGL Locks(kgllock),从而使得对库缓冲的搜索次数最小化,这样,我们就拥有一个到该对象的捷径(当打开/关闭游标时存储于PGA中)。当下次同样的语句发布时,我们就可以在PGA中找到该对象而不必再搜索相应的哈希桶链表(软软解析)。

我们应该避免长时间持有Latches。这就意味着当我们对已发现的某个内存区域做一些耗时处理时,可以将该对象Pin住,以保护我们正使用的内存区域,从而我们能释放相关Latch。

a)  获取覆盖相应哈希桶的Latch;

c)  将该对象Pin住并释放相应Latch;

e)  获相应Latch,Unpin该对象并释放相应Latch;

 

可以通过三种主要方式可以获取KGL Locks:

2)  用户可以设置session_cached_cursors参数,以使得Oracle看到用户使用一条语句多于两次时,库缓冲将自动持有相关游标;

 

除了最小化我们搜索对象时对库缓冲的检索次数外,该Locks还提供如下好处:

2)也被称为解析(Parse)Locks的库缓冲Locks用于维护对象及其依赖对象的依赖机制。

5.  为什么需要库缓冲Pins(KGL Pins)?

Pin住对象会导致其相关堆被加载进内存。如果一个用户想修改或检查该对象,则必须获取Lock后再获取Pin。

库缓冲对象上Locks及Pins的相关信息可通过三个X$表进行查询,即x$kgllk, x$kglpn和x$kglob.

2)x$kglob包含Locks资源项;

 

库缓冲锁及钉住(Locking和Pinning)机制也许会导致两个问题。

 KGL Locks及Pins相关的另一个问题是,当使用它们时,必须频繁的创建内存区域,标明属性,将它们插入链表(或移出链表并将其放回共享池),期间,这些操作需要一直持有独占模式的Latch,对繁忙的系统来说,整个库缓冲Locks及Pins将带来很大威胁。

 

为了改善游标的执行和硬解析,Oracle 10gR2版本引入了一个新的、更好粒度的内存串行机制。对某些共享游标相关的操作,Mutexes(Mutual exclusion objects,互斥对象)可用来替代库缓冲Latches和库缓冲Pins。Mutex工作方式与Latch基本相同,但操作Mutexes的代码路径更短,更轻量级,通常也会被硬件直接支持。因此,与Latch机制相比,Mutexes会更快,耗费更少的CPU,并发性方面也会有很大提升。32位Linux系统上,常规Latch结构占用110字节,而Mutex仅占28字节。而Mutex消耗的指令也更少。获取一个Latch需要消耗150~200个指令,而获取一个Mutex则只需大约30-35个指令。

 

Mutexes可以共享或独占模式获取,也可以等待或非等待模式完成。

2)替换Latches和Pins:Mutexes具有双重性。其可以作为一种串行机制(像一个Latch),同时也可以作为一个Pin(例如:阻止对象从内存中被移除)。 一个Latch不能被多个会话同时获取,而一个Mutex可以被多个会话同时参考,多个会话可以共享模式参考该Mutex。以共享模式参考一个Mutex的总会话数被称为参考数(Ref Count)。一个Mutex的参考数被存储于其自身。一个Mutex也可以独占模式被一个会话持有。

除了每个子游标句柄中有Mutex结构且其作为游标Pin结构而带来的主要好处。如果你正有一个游标被打开(或在会话游标缓冲内),你不必获取库缓冲Latch(而之前为了改变游标Pin状态而必须这么做),就可以直接修改游标Mutex的参考数(通过会话UGA内打开游标状态区域的指针)。

 

1) 库缓冲Latch机制在解析等操作中依然被需要,Mutexes仅仅解决了库缓冲的Pin问题。

3)由于Mutexes是一种通用机制(而非库缓冲专用),其也被用于V$SQLSTATS底层结构。

5)Latches和Mutexes为独立的机制,即一个进程可以同时持有Latch和Mutex。Oracle10.2.0.2以上的版本中,只要“_kks_use_mutex_pin”参数被开启,库缓冲Pin Latch将被Mutex替代,同时,其他一些类似V$SQLSTATS数组及父游标检查的操作也被Mutexes保护。然而,使用kksfbc()的真正子游标查找依然被库缓冲Latches保护,但是,频繁软解析加上很少的游标缓冲及较长的库缓冲哈希链将导致这些Latches成为一个问题(记住,即使在普通的哈希链扫描中,库缓冲Latch始终被以独占方式获取)。

Oracle 11g版本中,有另外一些Mutexes,其中最重要的一个是库缓冲Mutex。同时,除了“library cache load lock”外,所有库缓冲相关的Latches都消失了,取而代之,相应操作都被Mutexes保护。“libarary cache”Latches已被“library cache”Mutexes替代。

librarycache pin allocation

librarycache hash chains

librarycache

而Oracle 11g版本中仅剩的Latches为:

下列出现于Oracle 10g版本的与库缓冲相关的等待事件在Oracle 11g版本中也不复存在:

latch:library cache lock

Oracle 11g版本中与库缓冲相关的等待事件为:

librarycache lock

librarycache: mutex X

OSD IPClibrary

librarycache shutdown

 

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

主题测试文章,只做测试使用。发布者:深沉的少年,转转请注明出处:http://www.cxybcw.com/184896.html

联系我们

13687733322

在线咨询:点击这里给我发消息

邮件:1877088071@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code