注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

风之人生

人生如风,却无法如风般潇洒。

 
 
 

日志

 
 
关于我

一介草民,苟活于上海滩,以甲骨文为生,偶尔对一些国家大事有些兴趣,日常无事常以丝竹之声为乐。

网易考拉推荐

Oracle Mutex  

2010-07-24 21:27:05|  分类: Oracle |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

 在Oracle 10g release2里面,引入了一个新的锁机制,类似于以前的latch,叫做mutex.以下是关官方说明:

Mutex is the short form mutual exclusion object.
A mutex, similar to a latch, is a low-level serialization mechanism used to control access to a shared data structure in the SGA.
Serialization is required to avoid an object being:
- Deallocated while someone is accessing it
- Read while someone is modifying it
- Modified while someone is modifying it
- Modified while someone is reading it
Mutexes can be defined and used in different ways, as in the following examples:
- Each structure being protected by a mutex can have its own mutex (for example, a parent cursor has its own mutex, and each child cursor has its own mutex)
- Each structure can be protected by more than one mutex, with each mutex protecting a different part of the structure.
- A mutex can protect more than one structure.
Although mutexes an latches are both serialization mechanisms, mutexes have certain features that latches do not:
- Smaller and Faster
Mutexes are an alternative to latches because they are smaller and much faster to get. A mutex get uses fewer instructions compared to a latch get. A mutex takes less memory space compared to a latch.
- Less Potential for False Contention
Latch typically protect multiple objects. When a latch protects one or more hot objects, the latch itself can become a serialization point when accessing any of the objects protected by that latch. This can be a false contention point, where the contention is for the protection mechanism (that is, latch), rather than the target object you are attempting to access. Unlike latches, with mutexes it is possible to create mutex for each structure protected. This mean that false contention is much less likely because each structure can be protected by its own mutex.
- Replace Latches and Pins
A mutex can be concurrently referenced by many sessions, providing all sessions reference the mutex in S (Shared) mode. The total number of sessions referencing a mutex in S mode is called the reference count ("ref count"). The ref count for a mutex is stored within the mutex itself. A mutex can also be held in X (eXclusive) mode by one session only.
Mutexes have a dual nature; they can act as a serialization mechanism (for example, latch) and also as a pin (for example, preventing an object from aging out). For example, the ref count of a mutex is a replacement for a library cache pin. Instead of each session creating and then deleting a library cache pin when executing a cursor, each session increments and decrements the ref count (so the ref count replace n distinct pins).
Note: Latches and mutexes are independent mechanisms, that is, a process can hold a latch and a mutex at the same time.
Mutex operations are faster and have less contention than latches, but mutex operations still have waits associated with them. Two V$ view provide detail of mutex sleeps:
- V$MUTEX_SLEEP shows a summary of sleeps and wait time for particular mutex_type/location combination.
select * from v$mutex_sleep;
MUTEX_TYPE LOCATION SLEEPS WAIT_TIME
-------------------------------- ---------------------------------------- ---------- ----------
Cursor Stat kksIterCursorStat [KKSSTALOC6] 103 163
Cursor Stat kksFindCursorStat [KKSSTALOC3] 23157 36724
Cursor Parent kksfbc [KKSCHLCREA] 1799 10170
Cursor Parent kkspsc0 [KKSPRTLOC27] 26 627
Cursor Parent kkspsc0 [KKSPRTLOC26] 122 2872
Cursor Parent kkshbbr [KKSPRTLOC15] 660 1779
Cursor Parent kksLoadChild [KKSPRTLOC4] 1181 6932
Cursor Parent kksfbc [KKSPRTLOC2] 9006 34053
Cursor Parent kksfbc [KKSPRTLOC1] 2831 144439
Cursor Pin kksLockDelete [KKSCHLPIN6] 5021 1055990
Cursor Pin kkslce [KKSCHLPIN2] 265549 2792810468
Cursor Pin kksfbc [KKSCHLPIN1] 1203 5132409
Cursor Pin kksfbc [KKSCHLFSP2] 9279 56902065
- V$MUTEX_SLEEP_HISTORY show sessions sleeping for a particular mutex_type/location combination by time while it is held by a specific holding session.
Mutex wait event have two categories:
- cursor:mutex indicates that the mutex waits on parent cursor operations and statistics block operations.
- cursor:pin events are wait for cursor pin operations, where a mutex has replaced the latch:library cache pin.
Mutex wait events are of two types:
- Short-duration events that should rarely be seen. These occur when one process attempts to update the mutex while it is being changed by another process. The waiting process will spin waiting for the mutex to be available. For example, cursor:pin S is incremented when another process is updating the reference count(pin) of shared cursor.
- Long-duration events occur when a process must wait for other processes to finish their operation. For example, cursor:mutex X is incremented when a process wants an exclusive access but the mutex is being held exclusive or shared by another process.
Mutex-Protected Operations:
A mutex is another protection mechanisms that can protect critical operations. From Oracle database V. 10.2.0.2 and later, a SELECT from the V$SQLSTATS view is protected by mutexes. The use of mutex-protected operations is significantly faster than latched operations. The child cursor lists are protected by mutexes.
 
借此参考。
  评论这张
 
阅读(498)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017