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.

First, consider if numbers must be displayed. Showing numbers can lead to detailed discussions that may not be necessary and can be distracting. If you show numbers, be ready to answer questions like, "What is a user call and how does that relate to performance?" If you don't want to answer this because it is a clear distraction to your objectives, then do not show these numbers.