When looking at all sessions together as a single unit of work, known as profiling the system, while some SNMFC wait events may be the result of a network or client processing issue, the vast majority of the SNMFC postings will be from both an idle client and server processes patiently waiting for something to do. This is why most wait event reports filter out this wait event. In fact, because most Oracle sessions spend more time waiting than doing work, if the SNMFC wait time were included in the typical wait event report, it would effectively dwarf all the other wait time we dearly care about and desperately need for our analysis.

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.