It is always best and more reliable to focus on one change at a time. As anyone working in IT has experienced, multiple simultaneous changes can have unanticipated effects. We need to know the impact of each change. Therefore, only one change will be implemented at a time.

Because it's the easiest to implement and should result in a significant performance improvement, we will increase the buffer cache first. Increasing the buffer cache to 1GB will effectively cache the customer table, resulting in virtually no physical IO requests. From a total response-time perspective and looking at Figure 9-26, we see that the physical IO arrival rate will drop to nearly zero. So, it is insignificant how fast or how slow the requested blocks are returned to Oracle. Figure 9-22 shows physical IO accounts for nearly 30% of the total Oracle response time. By eliminating nearly all the physical IO, assuming the users don't perform more work and we don't hit some locking type of performance issue (for example, row-level locking), general performance will improve by 30%.

Users who unknowingly run multiple queries at the touch of a button, waiting for the application to return control to them and getting upset, are highly likely to feel the effect of the Oracle in-memory queries! Figure 9-24 shows that both logical and physical IO response times are around 0.022 ms. In Figure 9-23, notice that all of the top ten statements have nearly the same number of physical IO and logical IO activity. This means that by eliminating the physical IO-that is, ensuring the tables are completely cached-we would expect the elapsed time to drop by half. Figure 9-24 shows the top SQL statement average elapsed time is 0.632 ms/exec. By increasing the Oracle buffer cache, average elapsed time is likely to drop to perhaps 0.316 ms/exec (0.632/2).