If you have multiple samples (for example, you are running reports, pulling from the Statspack tables), you will know if a good unit of work has been chosen because the resulting graph will look somewhat like a response-time curve. As Figures 9-9 and 9-10 demonstrate, it won't be perfect, but it should have an elbow in the curve.

A good unit of work will also help you identify the high-impact SQL that deserves attention, forging a strong link between Oracle and the operating system. For example, if there is a CPU bottleneck with the top wait event related to CBC latch contention, then we would normally look for the top CPU-consuming SQL and the top logical IO SQL (shown as Gets in AWR and Statspack). If we select logical IO as our unit of work, we are likely to get a good response-time graph, and because the graph's arrival rate is based on logical IOs, we can naturally present how, by identifying and tuning the high logical IO SQL, we will move out of the elbow of the curve. So, picking a good unit of work is more than a technical exercise. It is also relevant in communication, performance improvement strategy, and anticipation of the impact of the proposed solution.

Just as when you are asked what you do for a living and start with, "I work in IT," when initially and graphically conveying the performance situation using a response-time graph, start at a very abstract level. Obviously, this is particularly important when presenting to a nontechnical audience.