Let's use Figure 5-12 as an example. Figure 5-12 is OraPub's interactive instance-level ORTA report. In summary, it gathers initial statistics, sleeps for the given interval (in this case 120 seconds), wakes and gathers statistics again, and reports their differences. Basic stuff, I know, but this report shows both service time and wait time, and sample active SQL during the report interval (not shown). Given the same workload (which is not shown on this earlier version of rtsysx.sql), our objective is to reduce the response time (shown as 305 seconds)-not just reduce the service time (shown as 119 seconds) or the wait time (shown as 186 seconds).

Figure 5-12. This OraPub 120-second interval response time report clearly shows Oracle processes are suffering from intense cache buffer chain latch contention. A response time-focused analysis will work on reducing the response time, not only the wait time or the service time.

Most Oracle DBAs will look at the 168 seconds of cache buffer chains time and focus on reducing the wait time, without regard to the effect on service time or the Oracle workload (not shown). Suppose they decide to increase the spin count. While this may indeed reduce latch sleep time, it will very likely also increase CPU consumption! If the DBA is lucky, this may result in a net response time decrease. While we appreciate luck and take it when it comes, that's no way to optimize systems or build a career. The solution here is to focus on reducing response time, because that is closer to what the user experiences.