The time model views clearly differentiate background and server process time, plus we still can gather the parse time and recursive time values from v$sysstat. To save paper, I did not paste in a sample script. However, the script is very similar to the one shown in Figures 5-3 and 5-4. It's just a little more complicated because two views are used (v$sysstat and v$sys_time_model) and we have one additional class for the background process CPU consumption.

Let's classify the service time based on the Oracle Database 10g Statspack report shown in Figures 5-8 and 5-9. The Statspack report (as does an AWR report) converts the Figure 5-8 time system model statistics into seconds, but the Figure 5-9 instance statistics need to be converted appropriately. For CPU-related time, the instance statistics, which are based on v$sysstat, are shown just as if they were queried directly from v$sysstat, which is in centiseconds. Based on the system time model statistics shown in Figure 5-8, the total CPU consumed by the Oracle instance during the 26-hour Statspack interval (I realize this is an unusually long report interval, but this is what one of my students sent me to help diagnose his system) is 48,126.3 seconds, which consists of DB CPU (Oracle server processes only) time of 45,551.6 seconds and background cpu time of 2,574.7 seconds. Based on the Statspack's instance activity report, the parse time CPU consumption (not the elapsed time) is 187.69 seconds (18,769 cs) and the recursive CPU consumption is 6,425.75 seconds (642,575 cs).

Notice that the instance CPU consumption figure based solely on v$sysstat is 33,020 seconds (statistic CPU used by this session), whereas based on the time system model, the CPU consumption is 48,126 seconds. Even with subtracting the time model's background CPU figure, the v$sysstat value is off by around 30%. This is a good example of why you want to use the time system model whenever possible.