This is where the real fun-and also the real risk-begins. The moment you draw a picture of your system, all eyes will be focused on you. Your objective is to convey the situation as simply as possible, without misleading anyone. Simplicity and abstraction are your friends. The moment you attempt to be precise or get heavily into the mathematics, you're doomed. This book is not about predictive performance analysis, and this is not our focus here either. Our goals are to convey the situation and anticipate the general effect of our proposed solutions. Providing more information promotes better decisions about which solutions to implement and in what order.

While the examples used in this section are based on an entire Oracle instance activity, everything described can also be applied to a single session or a group of sessions. For example, instead of gathering CPU consumption and wait time from v$sysstat, v$sys_time_model, and v$system_event, when focusing on a particular session or group of sessions, use v$sesstat, v$ses_time_model, and v$session_event. Obviously, to calculate operating system utilization, the v$osstat view will have to be used. But a session's or group of session's contribution to the utilization can be calculated in the same way as the Oracle instance CPU utilization (which is simply called Oracle CPU utilization).

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.