When creating a response-time graph representing a real system, it is important to use an appropriate unit of work. For your graph to provide value-mimic and show any relation to reality-it must use a unit of work that relates to the queue time issue. For example, as Table 9-2 shows, if the bottleneck is CPU, logical IO processing will mostly likely correlate very well with CPU consumption. If the bottleneck is IO, the number of SQL executions, the number of block changes, or the number of physical block reads may correlate very well with the IO activity.

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.