You were brought to this page based on an internet search
and as a free service to Oracle DBAs.
The text below is an except from the book,
Oracle Performance Firefighting, written by
Craig Shallahamer of
OraPub, Inc.
Figures and tables are not included on this page, only their reference.
To order the book in either print or PDF form, click
here.
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
PleaseOut of respect for those involved in the creation of the book and also for
their familes, we ask you to respect the copyright both in intent and deed. Thank you.
-------------------------------
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).
With an increase in performance (decrease in response time), users may perform work more rapidly, increasing the workload. The more time users are sitting and waiting for the application to return control to them, the more of a workload increase we can expect to see. It is possible a significant increase in the workload could offset the gain in response time. But either way, the users win. If they don't increase the workload, online performance increases. If they do significantly increase the workload, they will get more work done!
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
PleaseOut of respect for those involved in the creation of the book and also for
their familes, we ask you to respect the copyright both in intent and deed. Thank you.
|