When performing an ORTA, we gather all of a category's time within a sample interval. For example, consider the data presented in Table 9-1. This hypothetical data was gathered during a 1-hour interval, during which Oracle server and background processes consumed (required) 50 seconds of CPU time. We will place this 50 seconds of CPU consumed into the service time category. During this 1-hour interval, Oracle processes completed 20,000 block changes and 10,000 SQL executions. These are two metrics commonly used to represent the total workload. The block change service time is therefore 0.00250 s/bc, which is the total service time divided by the total block change workload (0.00250 = 50 / 20000).

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.