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.

Ask an operating system tuning specialists which is better: a calm and evenly paced system or one with wild and dynamic load swings. Most will say that they prefer the calm option. Quick and intense process scheduling activities result in large run queue variances and increased CPU consumption. Notice anything special about the Oracle sleep times? They are all multiples of 10 ms! This means during very heavy latch contention conditions, every 10 ms, many Oracle processes will wake up from their slumber and need to be placed back onto the CPU run queue. Once the CPU has dwindled down the run queue, it will receive another jolt, and so on and so on.