Once I present a few more foundational elements, in addition to Figure 9-7, I will demonstrate how Oracle systems do, in fact, operate in a manner that follows queuing theory, and by performing an ORTA, we can indeed anticipate our proposed solution's effect. And this does not apply only to Oracle-centric solutions, but also to application-focused and operating system-focused solutions.

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.