For example, one way to explain the performance situation is to say, "Oracle's wait time is composed of 55% db file scattered reads, 35% db file sequential reads, and 10% various wait events." A more effective way to start the conversation would be to say, "Oracle response time is all about IO. And if you look into the details, you'll find that reading multiple blocks per request from the IO subsystem is what's really hurting performance." This more simplistic approach is not misleading and should not be condescending, yet it communicates exactly what needs to be understood.

As DBAs, we have many ways to classify time, which gives us many options when communicating concepts to a variety of audiences. I personally use a very simplistic classification scheme for both service time and queue time. Oracle began classifying its wait events in Oracle Database 10g, which uses 12 classifications; 11g uses 13. For performance firefighting, I find it much more useful to keep the number of classifications to around 4.

Figure 2-14. Various levels of Oracle-focused time classification. The contents could be the result of a one-hour snapshot of all Oracle activity or the result of profiling a specific Oracle transaction. There are numerous classification schemes. The schemes shown here are exceptional for firefighting purposes. When combined with a response-time curve, the communication impact is phenomenal.