As you can image, in a busy system, making repeated fast attempts to acquire a latch can be exhausting. So after the specified _spin_count attempts have been made, and the latch has not been acquired, the spin_get function returns FALSE and, as can be seen in Figure 3-6, the process falls into the sleep portion of the spin-sleep loop.

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.