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.

Now let's relate Oracle's latch acquisition algorithm and time accounting to a real-life Oracle system.

Figure 3-9 is not based on queuing theory, and it is not a model. Figure 3-9 is based on actual data sampled from a real Oracle system. A heavy logical IO load was placed on a single four-core CPU Oracle Database 10g Release 2 Linux system. Six 3-minute samples were taken at each load, and then the load was incremented with another three Oracle sessions. The graph in Figure 3-9 shows the following: