关于latch和mutex的问题

latch是闩锁，是一种串行化机制，用来保护SGA中的内存结构。
mutex是什么，也是一种串行化机制，是互斥锁？
个人对mutex没有什么概念。这个是10G新引进的？9I好像没有啊。

哪位明白人，给帮忙详细解释下mutex，最好还能和latch 做下比较。

谢谢。

BTW, things get more fun in 10.2, you can pin cursors without getting library cache pin latch, using KGX mutexes. Mutexes are new in 10.2 and they enable shared access to objects in somewhat similar manner to shared latche; every successful get of a particular mutex will increment its value and a release will decrement. When the count is zero, no one has the mutex and it is safe to get it in exclusive mode. However, they are more fine-grained than kgl latches and provide a better wait mechanism, as far as I understand.
So if your environment supports atomic compare and swap operation (such as CMPXCHG on Intel), you might get away without cursor_space_for_time setting for ultrahigh execution rates. Otherwise the atomic mutex operations would be achieved using the new KGX latches.
At least on my laptop this feature isn't enabled by default (from an OracleWorld paper I remember that it should become default in 10.2.0.2), but so far you can experiment with it if you set _kks_use_mutex_pin = true and bounce the instance (mutex structures will be stored in the shared pool, so you might need to increase shared pool size).

There are also X$MUTEX_SLEEP and X$MUTEX_SLEEP_HISTORY fixed tables that can show some interesting information if you generate some mutex waits into them.

Now, I don't suggest for a moment that you have to understand this response. It is at an extremely deep technical level, and the practical applications of such understanding are probably few and far between. My point, though, is that you must take the time to study and understand Oracle internal operations if you are to have success in Oracle performance optimization. There are no shortcuts to making a database application run efficiently. You must understand good SQL practice, good PL/SQL practice and good host-language practice for starters. Beyond that, you ought to know how Oracle manages concurrency, how Oracle processes SQL statements and how Oracle performs data and code (SQL and PL/SQL) caching. If you're asking the question "How do I set up an Oracle database for optimal performance?" you have a long way to go. Don't try to avoid the effort; take the time to study and learn, and you will reap the rewards.

谢谢了。

[quote]原帖由 [i]zhouwf0726[/i] 于 2008-6-12 23:21 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=10647164&ptid=1004815][img]http://www.itpub.net/images/common/back.gif[/img][/url]
BTW, things get more fun in 10.2, you can pin cursors without getting library cache pin latch, using KGX mutexes. Mutexes are new in 10.2 and they enable shared access to objects in somewhat similar manner to shared latche; every successful get of a particular mutex will increment its value and a release will decrement. When the count is zero, no one has the mutex and it is safe to get it in exclusive mode. However, they are more fine-grained than kgl latches and provide a better wait mechanism, as far as I understand.
So if your environment supports atomic compare and swap operation (such as CMPXCHG on Intel), you might get away without cursor_space_for_time setting for ultrahigh execution rates. Otherwise the atomic mutex operations would be achieved using the new KGX latches.
At least on my laptop this feature isn't enabled by default (from an OracleWorld paper I remember that it should become default in 10.2.0.2), but so far you can experiment with it if you set _kks_use_mutex_pin = true and bounce the instance (mutex structures will be stored in the shared pool, so you might need to increase shared pool size).

There are also X$MUTEX_SLEEP and X$MUTEX_SLEEP_HISTORY fixed tables that can show some interesting information if you generate some mutex waits into them.

Now, I don't suggest for a moment that you have to understand this response. It is at an extremely deep technical level, and the practical applications of such understanding are probably few and far between. My point, though, is that you must take the time to study and understand Oracle internal operations if you are to have success in Oracle performance optimization. There are no shortcuts to making a database application run efficiently. You must understand good SQL practice, good PL/SQL practice and good host-language practice for starters. Beyond that, you ought to know how Oracle manages concurrency, how Oracle processes SQL statements and how Oracle performs data and code (SQL and PL/SQL) caching. If you're asking the question "How do I set up an Oracle database for optimal performance?" you have a long way to go. Don't try to avoid the effort; take the time to study and learn, and you will reap the rewards. [/quote]


who wrote that? :ipride:

[url]http://dba.5341.com/msg/58669.html[/url]

[quote]原帖由 [i]netbanker[/i] 于 2008-6-13 02:49 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=10647587&ptid=1004815][img]http://www.itpub.net/images/common/back.gif[/img][/url]



who wrote that? :ipride: [/quote]


当时搜索到的。



这个更清晰些：

[url]http://yumianfeilong.com/2007/05/23/mutexes-in-oracle10g/[/url]

SQL> show parameter kks

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_kks_use_mutex_pin                   boolean     TRUE
SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0      Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production

[b]今天有人问：
show parameter kks怎么没有结果，因为我的环境该变量没有使用默认值。[/b]

15:54:57 SQL> SELECT NAME,VALUE,ISDEFAULT FROM V$PARAMETER WHERE NAME LIKE '%kks
%';

NAME                           VALUE                          ISDEFAULT
------------------------------ ------------------------------ ---------
_kks_use_mutex_pin             TRUE                           FALSE

[b]当然我们利用其他方法show hidder parameter ：[/b]

[url]http://space.itpub.net/?uid-756652-action-viewspace-itemid-468211[/url]

oracle很多东西在内存里是通过latch保护的，latch最大的一个问题就是少，对用户来说，library cache pin，cbc, enqueue hash，这些都是一个保护多个，实际上造成我在需求a的时候，因为保护a的latch正在保护被调用的b，而导致我没有办法访问到本来就没有被访问的a，很恶心，这样做可能是因为latch需求太高，如果极端的实现一对一保护，会占用大量的资源，搞不定，mutext很可能就是提高这些，尽可能达到一对一，降低cpu这些资源，还是感觉挺不错的，不过10r2开始的时候，至少到10204还是有cursor mutex的bug。