Oracle Performance Firefighting
by Craig Shallahamer

Get the book here



Craig Shallahamer's Blog

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.
Please—Out 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.

-------------------------------

Latches and mutexes are deeply involved with memory structure control. In fact, they are both small memory structures themselves! Memory structure access must be exceptionally quick. For example, perhaps a server process wants to know if a single block is in the buffer cache. If a SQL statement must touch 5,000 blocks, and each time the question, "Is the block in the buffer cache?" is asked, which takes 1 ms, it will take 5,000 ms (5 seconds) just to determine if the blocks are in Oracle's cache! This time does not include actually accessing the buffers, asking the operating system for the blocks if they are not in the cache, and other cache management requirements (discussed in Chapters 6, 7, and 8). So, every millisecond counts with memory access. Oracle goes to great lengths to reduce the number of times a latch or mutex is requested, and also in optimizing the code so that once a latch or mutex is acquired, it's not held long.

When relational objects are locked, it's like the locking process is tightly clutching the object and telling others to back off. In contrast, memory structure control is more like acquiring a token, which is the control structure. Once the process has the control structure, it is then, and only then, allowed to access the memory structure. So, memory structure access is indirect. First, you must acquire the control structure, and then you can run the kernel code that accesses the memory structure. A good mental model of this is to think of a latch or mutex like the baton in a track race relay. Once you have the baton, you are free to run!

Figure 3-2 shows the three main components; kernel code modules, control structures, and the control structure's associated memory structure. The control structures could be either latches or mutexes. Figure 3-2 shows that module A has acquired control structure CS101. So, module A is now free to run the kernel code that accesses memory structure MS1. Module Z has acquired control structure CS411 and is authorized to run the kernel code to access memory structure MS3. Both module B and module X are attempting to acquire control structure CS411, because they want to access memory structure MS3. However, module Z has acquired control structure CS411, and so both module B and module X must wait.

©2009, 2010 by Craig Shallahamer. This is copyrighted material.
Please—Out 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.


Know what's important before it's too late!

OraPub's
Performance Training

is like no other...





More Class Pics...
Get student testimonials!