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.

Essentially, Oracle has extended the instrumentation approach into service time-that is, CPU consumption. While the time model is not perfect, and there are still only two service time classifications, it's a significant leap forward and sets the stage for some truly amazing self-aware, self-tuning, and self-adjusting features. So this is a very big deal, and it works wonderfully.