From the previous chapters, you know that response time equals service time plus queue time. In fact, at the highest level, our Oracle firefighting methodology is based on classifying time in response time's two foundational categories: service time and queue time. Not only does this allow a very systematic diagnostic approach, but it also provides a wonderful and natural bridge between firefighting and predicting the impact of our possible solutions. Before we move into quantitatively anticipating our solution's impact, some additional details about service time, queue time, and response time specifically related to Oracle systems need to be covered.

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.