When performing an Oracle response-time analysis (ORTA), we place Oracle server and background process time into the classic queuing theory buckets: service time and queue time. Keeping in mind that all Oracle server and background processes are either consuming CPU or posting a wait event,3 as I'll detail in the following sections, we naturally transform their CPU time into service time and their non-idle wait time into queue time. This creates a bridge, or link, between firefighting and predictive analysis. This bridge is supported by standard queuing theory mathematical formulas, some already presented in earlier sections, which we will use to quantify the anticipated results of our firefighting solutions.

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).