With its amazing marketing machine, in the early 1990s, Oracle introduced client/server computing. As shown in Figure 5-16, this allows the server and client processes to run on different machines while communicating via SQL*Net. For end-user computing, the client process typically resided on the user's PC. However, for batch processing, it is common for both the client and server processes to remain on the database server. I don't know if the Oracle architects planned for the client and server process separation, but regardless, Oracle's two-task architecture fit perfectly into this model and helped systems scale (not to mention Oracle's stock price). From a session profiling perspective, it was still a fairly simple task to associate an end user with both a client and server process.

Figure 5-16. Oracle's client/server architecture. Notice the Oracle client process has been shifted from the database server to the end user's PC. This allows the client process to focus more on the user experience at the cost of increased PC computer power requirements, PC maintenance issues, and increased network activity.

In the 1990s, memory was relatively expensive and the maximum physical addressable memory was limited. Oracle systems also continued to grow larger and larger. For Oracle systems to continue to scale and support more users and processing, Oracle needed to find a solution. As shown in Figure 5-17, this solution was to allow a server process to be shared by multiple clients. This was ingenious, because for OLTP processing, server processes are more idle than busy (this is why we typically filter out the SNMFC wait event). By creating a shared-server process, Oracle systems could continue to scale.