Keep in mind the process is just gaining permission to access a memory structure. Perhaps it just wants to check if a block is in the buffer cache. This time does not include the actual memory structure access, but only the acquisition of the control structure! For example, suppose a SQL statement touches 1,000 buffers and each "Is the buffer in the cache?" check takes 2 seconds. Then just to get permission to answer the question-not the time to actually scan the memory structure, to bring the requested blocks into the cache, or to perform any other memory activity-will take 2,000 seconds! As you can see, severe latch contention has the potential to cripple an Oracle system.

Looking closely at the Sleep function's decode statement in Figure 3-7, you will notice a tilde (~) preceding the 40, 80, and 2000. This represents randomness. In fact, especially in a busy Oracle system, the latch sleep time will not be exactly 40 ms, 80 ms, or 160 ms. And there is a good very reason for this!

Imagine you have a boiling cup of coffee and you need to quickly walk across a room. As you briskly walk, you will notice an oscillation pattern develop in your coffee cup. If conditions are not in your favor and you continue your brisk pace, the oscillation pattern will cause some of the coffee to spill on your hand, and you will scream (or at least your eyes will water).4 You have a couple of options. First, you could stop, and the oscillation pattern will subside. But since this is an Oracle process illustration and there is a benchmark to reach, slowing or stopping a process is absurd. Another very creative option is to slightly shake the coffee cup. If done correctly, the oscillation pattern will be disrupted and subside. In a very real sense, you have placed some randomness, or at a minimum, disrupted a potentially harmful situation.