As I will detail in Chapter 5, it is very convenient for DBAs when service time is CPU time, and queue time is Oracle wait-interface time. Think of the arrival rate as the Oracle workload. If you are familiar with Statspack or AWR, you know that near the beginning of the report, you can find a series of load profile statistics. Any one of those can represent the arrival rate. When the response-time curve is used for predictive purposes, a model is developed based on one or more of the load profile statistics. Common Oracle arrival rate statistics are user calls, executions, and buffer gets.13

The graph shown in Figure 1-3 is based on a queuing theory model.14 So it's not real; it's an abstraction. Service time is never perfectly horizontal, and queue time does not occur exactly as we plan in real systems. All those Oracle optimizations and messy workload issues muddy up things a bit. However, transactions and computing systems do behave in a queuing-like manner. They must-it's their nature. I've been asked how I know a system will respond this way. The answer is always the same. That's how transactions behave, and so do humans when we become a transaction and enter a queuing system, such as the one at McDonald's.

When you perform ORTA, you construct a response time curve graph, or simply numerically detail its components (service time and queue time), based on what occurred during an interval of time. For example, Figure 1-3 could represent Monday morning between 9 a.m. and 10 a.m.