If this database server contained a single CPU core, then over the 120-second interval, the database server's CPU subsystem could supply a maximum of 120 seconds of CPU power to operating system processes. Said another way, this is the database server CPU capacity over a 120-second interval. Since Oracle consumed 10.01 seconds and the database server's capacity is 120 seconds, Oracle consumed 8.34% (10.01/120) of the available CPU. Said another way, Oracle is utilizing around 8% of the server's CPU. If this database server contains only this Oracle instance, then it is likely the operating system CPU utilization is around 12% to 18% (add between 5% to 10% for operating system overhead). This tells us that unless there are other processes consuming CPU from the database server, it is highly unlikely there is a CPU bottleneck.

In Figure 5-4, also notice that the CPU consumption is not parse time or recursive SQL time-intensive. In fact, both take less than 1% of the total CPU consumed. As I'll discuss in detail in the following chapters, when parsing or recursive SQL time starts increasing, shared pool-related latching begins to raise its ugly head.3

While the v$sesstat and v$sysstat instance statistics view CPU consumption data collection strategy provides useful information, it does have several flaws. As you learned in the previous section, statistics may not be updated until a database call completes; when a session disconnects, session-level details are lost; and background process statistics are not guaranteed to be collected. With the introduction of the system time model starting in Oracle Database 10g, the updates and background processes issues have been resolved, and the session disconnets problem is solved through the active session history capability discussed in the final section of this chapter.