Figure 5-15. Combining an Oracle client and server process into a single executable. This single-task architecture has the advantage of the Oracle process communicating through program function calls instead of SQL*Net. Just as with a two-task architecture (Figure 5-14), the same user experience and database server capacity issues exist.

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.