Figure 9-30 shows logical IO response time decreased to 0.009354 ms/lio from 0.02199 ms/lio (Figure 9-24). Clearly, there was a significant service time change. This means initially Oracle was burning CPU cycles on other tasks besides accessing buffers that already resided in the cache. This is another example of the overhead involved in bringing buffers into Oracle's cache and updating all the related memory structures. As a result of the service time drop, the response-time curve will shift down and to the right, as shown generally in Figure 9-17 and especially in Figure 9-31. This explains why SQL statement elapsed time decreased and utilization decreased, while the workload increased.

Figure 9-30. Shown is the workload diagnostic information. Compared to Figure 9-24, logical IO response time dropped from 0.02119 ms/lio down to a staggering 0.00935 ms/lio. In addition, the overall logical IO workload increased from 69.29 lio/ms to 74.66 lio/ms, representing an 8% increase. So again, performance has improved while the workload has also increased.

Figure 9-31 shows the initial and current (buffer cache increase) response-time curves using logical IO as the workload metric. The variables used to create the response-time curve are four CPU cores (M=4); service times (St) of 0.01507 ms/lio and 0.009326 ms/lio for the initial and increased buffer cache situation, respectively; and their various arrival rates of 69.3 lio/ms and 74.7 lio/ms, as indicated on the graph as points A and B, respectively. Because Oracle now performs less work per logical IO, the service time for logical IO decreased. As shown graphically in Figure 9-31, the performance situation changed from point A to point B, allowing both improved SQL statement elapsed time combined with an increase in workload and a reduction in CPU utilization.