After a few seconds of determining the differences between the ending and starting performance statistics, a report similar to the one shown in Figure 2-18 is created.

Looking closely at the report, notice that queue time accounts for 86% of the response time! Now look at the queue time summary and notice that most of the queue time is classified as Net+Client. The Net+Client time is the Oracle client process run time and network communication between the Oracle client process and the Oracle server process. If you spend a few minutes reviewing the report you can see how quickly a full understanding of the response time situation can be captured. An instance-level ORTA, combined with identification of the SQL being executed, can lead to a surgical solution.

Figure 2-18 mirrors a consulting engagement I had a number of years ago. That engagement presents an interesting view into why a typically filtered-out wait event can be very useful. I received a call from a company manager who suspected a performance issue was the result of an application he purchased from a vendor. But when he confronted the vendor, he was told that the problem was the database server. I suggested profiling a real user running the application. Because of the client/server architecture, once the user's Oracle server process was identified, it was simple to determine the Oracle session identifier. With the session identifier known, using the rtsess9.sql script, I profiled the poorly performing part of the application multiple times. (Interestingly, the user was on a different floor when this was done, and all our communications were through a speakerphone.)