Tuning Oracle, the application, or the operating system effectively reduces its requirements. For example, instead of a SQL statement consuming 5 seconds of CPU, it now consumes only 2 seconds of CPU. Thinking about the basic utilization formula of requirements divided by capacity, if requirements decrease and capacity remains the same, then the utilization must decrease. The only way to increase the utilization once again is to increase the requirements. One way to do this is to increase the workload; that is, the arrival rate. So, through tuning, we have provided the basic performance-enhancing options of decreased response time, increased throughput, or some combination of both.

From a queuing theory perspective, what really happens when service time drops is that a new response-time curve takes effect. Because the service time decreases, with no load on the system and therefore no queuing, the response time with minimal arrivals is less. So, the curve has shifted down. But it gets better. Because each transaction server (for example, a CPU core) can process each arrival quicker, it can process more arrivals per unit of time before queuing sets in, which shifts the graph to the right. So, tuning shifts the response-time curve down and also to the right!

Figure 9-17 graphically shows how tuning can affect a system. Starting at point A, the performance is unacceptable and highly variable. By tuning the application, Oracle, or the operating system, the response time decreases (that is, improves), and the system is operating at point B. However, now the administrators have a choice. By controlling the workload (the arrival rate), they can allow more work to flow the system without affecting the response time. Point C shows this negligible affect on response time by allowing the arrival rate to increase. So again, tuning provides the performance analyst with several options: decreased response time, increased workload, or a managed combination of both!