To summarize, by reducing both physical and logical block activity, performance can be significantly improved. This means SQL tuning and/or reducing SQL statement execution rates. Figure 9-23 shows there are three high-consuming physical IO SQL statements, with the top statement consuming more than twice as much physical IO as the second and third ones combined! Figure 9-24 shows the system is processing nearly 70 logical IOs each millisecond.

Figure 9-23. Shown is the essential application SQL information entered (obviously copy and pasted) into a template. All the information was gathered during the 30-minute collection interval from v$sql and represents only what was processed during the collection interval. Notice the most resource-consuming statement is not the slowest and consumes no more resources per execution than other statements. It's the combination of execution rate and per-execution resource consumption that makes it stand out.

The Oracle analysis has directed us to the most important application SQL, which is SQL needing blocks that do not currently reside in Oracle's buffer cache. By focusing on SQL with the highest physical IO consumption, we can significantly reduce the application impact. There is no guessing or gut feeling about this. It is a fact. However, we expect the Oracle-focused solution of increasing the buffer cache to have a profound impact, and the change requires only a single parameter adjustment and an instance cycle. We will want to reanalyze the situation during the second analysis cycle. So at this point in the analysis, we will wait before suggesting any application changes.