* The systematic analysis naturally created an easy-to-follow and convincing story containing plenty of abstraction for the nontechnical folks, as well as specific Oracle internals and even some mathematics to satisfy the more technically astute.

* There was no finger-pointing. Each subsystem was investigated and possible performance-enhancing changes discussed. The implemented recommendations were objectively selected based on the anticipated impact and ease of implementation. However, there was no discussion about application usage disruption, uptime requirements, and availability requirements. In real life, these issues almost always take precedence over performance.

Table 9-4 shows a rather dramatic and satisfying flow of performance-improvement metrics. There are a couple items worth highlighting. First, while the physical or logical IO workload dropped, the number of SQL statement executions increased. While not shown in this table, the key SQL statements had a continual elapsed time improvement. The reduction in SQL statement resource consumption occurred in conjunction with a decrease in CPU utilization and total Oracle response time. This is exactly the kind of result we want to see.