However, there are times when SNMFC is immensely useful, and every Oracle performance firefighter needs to understand this. Suppose we are watching both the end user and the corresponding server process very closely. So closely, in fact, that we discover that both the user and the Oracle server processes are waiting. The user is waiting for a query to complete, and the Oracle server process is patiently waiting for a message from its client process. This is a strange situation indeed and indicates there is problem between (but not including) the database server process and the end user. If this is confusing, read this again and refer to Figure 5-13.

If the problem were centered at the database server, the server process would be either consuming CPU or posting a wait event related to latching, IO, or perhaps an enqueue. But since the server process is posting an SNMFC, we know the problem is beyond the database server. If the problem were with the end user, the user would not be staring idly at the screen.

A story about one of my consulting engagements may clarify this concept. The architecture was classic client/server, with the server process on the database server, the client process on the user's PC, and the network allowing the two processes to communicate. The users told me when they executed a particular application function, it was taking around 30 seconds to complete. The DBAs and the operating system team noticed the database server was essentially idle, and expected the problem to be focused squarely on the vendor application. And as you would expect, the vendor proclaimed the database server was undersized. I told the DBAs that we needed to profile a session while running the key application function that was causing so much pain. Using only Oracle's performance views (that is, no tracing was involved), repeated tests resulted in this situation: