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.
-------------------------------
Relating this to Oracle, the bottleneck would be acquiring the control structure, not accessing the underlying memory structure. When complex memory structures are protected by a limited number of latches, solutions focused on the control structure are to either add control structures (for example, specialized governmental permit reviewers) or decrease the control structure access time (for example, streamline the permit review process). In Oracle terms, this means either add more latches and improve latch acquisition performance or optimize the kernel code accessing the memory structure. A creative option is to not use latches at all, but instead use a completely different structure that inherently provides both of these benefits-like a mutex! Reducing the likelihood of control structure contention is another reason mutexes are an attractive memory control option.
Pinning ensures a specific memory structure is not deallocated, removed, or destroyed. For example, if a process is accessing an Oracle block buffer, obviously the process would not want the buffer replaced by some other buffer. To prevent this from occurring, the accessing process pins the buffer. Kernel developers perform the pin, not DBAs. While DBAs can cache tables and keep programmatic structures in the library cache, Oracle kernel developers issue an underlying pin of a buffer or a cursor.
Latches and mutexes can be used to pin a memory structure. Every mutex has a variable called the reference count. It contains the number of processes that are currently referencing the mutex (in shared mode). Oracle uses the reference count to determine if an object is being pinned. If the reference count is greater than zero, Oracle knows the object is pinned and cannot be deallocated. When an object is being pinned, the corresponding mutex's reference count is incremented by one. When the object is unpinned, the reference count is reduced by one. As long as the reference count is greater than zero or the mutex is being exclusively held, every Oracle process knows the memory structure is being referenced by some process, and therefore it cannot be deallocated.
©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.
|