When an Oracle database server CPU subsystem is heavily utilized, we know performance will be significantly degraded. Knowing the degree of "badness" is not important when evaluating alternative firefighting solutions. So, when performing our ORTA, it is not a problem to abstract and simply call this value CPU service time.

When IO times are gathered using Oracle's wait interface, from Oracle's vantage point, it is actually more of an IO response time. When Oracle issues an IO request to the operating system, it waits until the IO request is satisfied. When the IO subsystem processes the IO request, there is service time (perhaps transferring the data) and queue time (perhaps disk latency and head movement). The gettimeofday system call Oracle issues does not distinguish IO service and queue time, and therefore Oracle has no way of knowing the classification. But just as with CPU time, this does not present a problem, primarily because as performance analysts, we are interested in how long an IO call takes. The time components of the call can be of interest, but it's the total time-the response time-we need to know.

When we perform an ORTA, we classify all IO time as queue time subclassification. This may seem like an unfortunate and desperate abstraction, but it actually fits perfectly from a database perspective. If no IO occurs, Oracle satisfies all requests consuming only CPU time. But as the workload increases and some of this work requires IO, response time begins to increase; that is, queue time begins to increase; that is, IO time begins to increase. The pattern fits very nicely into an ORTA.