The application situation has indeed changed, as shown in Figure 9-29. First, we can see that no significant physical IO is being consumed! Thus means increasing the buffer cache had its intended affect. We were hoping for a 50% decrease in elapsed time, to around 0.316 ms/exec. What actually occurred was an elapsed time drop from 0.632 to 0.266, which is a 58% decrease in response time! So, we met and exceeded our objective. It appears the users are also able to get more work done because the SQL statement execution rate increased from 25.6 exec/sec (see Figure 9-24) to 27.1 exec/sec (Figure 9-30).

Figure 9-29. Shown is the essential application SQL information. Notice there is no physical IO consumed. Compared to Figure 9-23, the top SQL statement's elapsed time per execution improved from 0.632 ms/exec to 0.266 ms/exec, while at the same time, the number of executions during the sample interval increased from 473 to 536.

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.