Figure 4-2 shows a four-CPU core subsystem in three different situations. Situation A is very busy CPU subsystem with two processes waiting in the queue. Situation B looks like a very idle CPU subsystem with only one active transaction. However, situation B could also represent a problem. If the transaction being serviced in situation B is a relatively long transaction, why are the other CPUs not participating, but instead standing idle? This is a scalability issue, and as mentioned in Chapter 3's discussion of serialization, everyone-from the businesspeople to the operating system vendors-gets involved, so this situation never occurs.

Situation C in Figure 4-2 is truly unfortunate. Because there is only one queue, there should never be a situation where processes are waiting in the queue while there are idle CPU cores. Can you imagine standing in a fast food restaurant line, and even though two servers are available, they look at you and tell you to wait? Absurd indeed, and if you ever see this occur (on a computer system), contact your operating system vendor!

* User time: This is when a core is spending time processing code, such as SQL*Plus, the oracle executable, or Perl scripts. Normally, Oracle database CPU subsystems spend about 60% to 90% of their active time in what is called user mode.