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.

Figure 2-18. Report output from a session-level ORTA based on a single and identifiable Oracle session. The session is waiting primarily for information from the client process, which leads the analyst to suspect issues with the client program or the network communication between the client and server process.