You were brought to this page based on an internet search
and as a free service to Oracle DBAs.
The text below is an except from the book,
Oracle Performance Firefighting, written by
Craig Shallahamer of
OraPub, Inc.
Figures and tables are not included on this page, only their reference.
To order the book in either print or PDF form, click
here.
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
PleaseOut of respect for those involved in the creation of the book and also for
their familes, we ask you to respect the copyright both in intent and deed. Thank you.
-------------------------------
Most Oracle sites will never experience mutex contention and if they do, the stress will probably be related to pinning a cursor in either shared or exclusive mode.
Interestingly, for mutexes to operate, the operating system must support the compare and swap (CAS) operation. Reduced instruction set computer (RISC) operating systems, such as AIX or PA-RISC, may have chosen to reduce their instruction set by eliminating the CAS operation. In situations like these, Oracle will simulate the CAS operation by using a pool of latches (1,024 by default in Oracle Database 11g Release 1). The latches are named KGX, and their number can be changed by altering the instance parameter _kgx_latches. Obviously, this is not optimal for performance, but one hopes the net result will be beneficial.
There are actually a number of mutex-related wait events, as listed in Table 7-1. While I would like all mutex-related wait events to start with mutex, Oracle has taken a different path. The mutexes associated with the library cache all start with the word cursor. It makes sense, since the library cache is full of cursors, but it makes discovering new mutex usage more difficult for the performance analyst.
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
PleaseOut of respect for those involved in the creation of the book and also for
their familes, we ask you to respect the copyright both in intent and deed. Thank you.
|