Table 9-1 also details the total queue time and the queue for a single arrival-that is, unit of work. The point is, as previously stated, there is a difference between the total service time and the service time, and also between the total queue time and the queue time. In addition, we can interject potentially useful and relevant arrival rate metrics, such as block changes, SQL executions, redo entries, block changes, or logical IO. Selecting a useful workload metric is discussed in the "Response-Time Graph Construction" section later in this chapter.

Back in Chapter 5, I mentioned Oracle has a limited perspective in classifying CPU time based on when a transaction is being serviced by a CPU or when it is waiting in the CPU run queue. In other words, Oracle does not have the ability to split CPU time into service time and queue time. When we gather CPU consumption from either the instance statistics views or the system time model views, what we collect as CPU time and typically classify as CPU service time actually contains both CPU service time and CPU queue time. Oracle has no way of knowing the difference and reports the total, which is, in the truest sense, CPU response time.

This type of perspective is common. In fact, computing systems are actually composed of a series of interconnected queuing systems. This is called a networked queuing system. An Oracle transaction does not really enter a single large system, wait to be serviced, is serviced, and then exits to return the result. It enters a complex series of queuing systems, moving from one system to the next, each with the possibility of queuing and then servicing the transaction. When the transaction exits the complete system, the sum of all the service time and the sum of all the queue times are presented as simply the service time and the queue time. So, this type of abstraction is very common.