So, we have the application users waiting for their application to respond and Oracle DBAs waiting for the Oracle process to acquire the latch, but I have made no mention of Oracle wait event time. I stated spinning on a latch consumes CPU time, but have made no mention of what constitutes the Oracle wait event latch free. If Oracle considered and recorded CPU spin time as wait time, yet it also recorded CPU spin time as service time, then Oracle would double-count the spin time. In other words, 20 ms spinning would result in a response time of 40 ms: 20 ms for CPU consumption while spinning and 20 ms for latch wait time.

Fortunately, Oracle does not double-count latch spin time. If you look closely near the bottom of Figure 3-6, just before the Sleep function call, you'll notice the wait event post. Oracle latch wait time reflects only the sleep time, not the spin time. This means that latch-related response time contains the CPU consumption during spinning and also latch sleep time. Stated another way, latch-related response time contains service time due to spinning on a latch, and the queue time is related to Oracle processes sleeping.

This has profound latch contention resolution implications. When you look at a wait event report or a response time report, all latch wait event time is latch sleep time, and not the related CPU time. In other words, when you see latch wait time or a latch wait event, you know the associated process has already been spinning and consuming CPU before the wait event was posted! This is why when there is intense latch contention, the DBA sees a lot of latch wait time and also a lot of CPU consumption. I'll provide more details about this in Chapter 5.