Figure 3-7 contains the sleep function pseudocode. Oracle dictates the amount of time the process sleeps before jumping back into the latch acquisition room. Interestingly, the first sleep does not contain any sleep time, but does ensure the very tight spinning loop is exited. If the process does not acquire a latch after two traumatic spinning attempts, then Oracle does insist the process sleep for 10 ms. From this point forward, every failed spin attempt will result in an increased sleep time, up to 2,000 ms. This may not sound like much, but demanding that an Oracle process stop what it's doing for 2 seconds is a performance disaster.

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!