When making a statement like this, someone is likely to ask how much more throughput can be expected. That's when it's time to once again show the response-time graph in Figure 9-25, which illustrates the current situation in a pure logical IO (CPU) perspective. If the service time does not decrease (this is detailed in the second analysis cycle), then it appears we can nearly double the workload before response time significantly increases. Unless you have a way to control the user workload or understand the application very well, there may be no way of knowing if the users can or will increase the workload. But regardless, you have graphically and with simplified numbers demonstrated the performance impact of increasing the buffer cache.

As described in the previous section, an Oracle buffer cache increase was chosen as the first performance-enhancing change. We are anticipating around a 30% decrease in total Oracle response time, and for users who run multiple serial queries at a single touch to feel around a 50% decrease in response time. We are not sure if users will be able to take advantage of faster response time and get more work done, but it won't surprise us if they can.

As Figure 9-27 shows and as we expected, physical IO has been virtually eliminated. The total service time has also decreased. We were hoping for a 30% drop in total response time. But when comparing the Oracle analysis shown in Figure 9-21 to Figure 9-27, we can see the total response time decreased from 2,644 seconds to 1,257 seconds, which is a 52% improvement! (A direct comparison was possible because the collection interval was the same: 30 minutes.) The large drop in service time is due to less cache management related to placing blocks into the buffer cache. The decrease in Oracle's CPU consumption should result in a drop in CPU utilization. Any further performance gain should now focus on reducing CPU consumption, which is squarely focused on heavy logical IO SQL.