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.)

Key to understanding a situation similar to Figure 2-18 is recognizing the single underlying wait event for the Net+Client queue time category is SQL*Net message from client. When a server process is waiting to hear from its client process, it will post the wait event SQL*Net message from client. A server process does not know if the user associated with the client process is waiting for the client process to complete, if there is a problem with the network, or if the user is taking a coffee break. All the server process knows is that it has nothing to do and is programmed to scream, SQL*Net message from client! In a very real sense, the server process is waiting for a message via SQL*Net from its client process. So, in this case, the wait event is actually very descriptive.