Back in Chapter 5, I mentioned Oracle has a limited perspective in classifying CPU time based on when a transaction is being serviced by a CPU or when it is waiting in the CPU run queue. In other words, Oracle does not have the ability to split CPU time into service time and queue time. When we gather CPU consumption from either the instance statistics views or the system time model views, what we collect as CPU time and typically classify as CPU service time actually contains both CPU service time and CPU queue time. Oracle has no way of knowing the difference and reports the total, which is, in the truest sense, CPU response time.

This type of perspective is common. In fact, computing systems are actually composed of a series of interconnected queuing systems. This is called a networked queuing system. An Oracle transaction does not really enter a single large system, wait to be serviced, is serviced, and then exits to return the result. It enters a complex series of queuing systems, moving from one system to the next, each with the possibility of queuing and then servicing the transaction. When the transaction exits the complete system, the sum of all the service time and the sum of all the queue times are presented as simply the service time and the queue time. So, this type of abstraction is very common.

* It allows our performance analysis to move forward without insignificant details getting in the way of the problem at hand. Our goal should always be to keep situations as simple as practically possible. Added complexity and precision take effort and resources that should not be expended unless absolutely necessary.