As shown in Figure 5-14, in the 1980s, both Oracle's SGA and the Oracle server and client processes resided on the database server. It's important to understand that because the Oracle server process works directly on Oracle's cache (which resides on the database server in shared memory segments), the server process must also reside on the same machine as the SGA. So regardless of all the creative and fascinating Oracle architectures we can think of, each requires the server process and the SGA to be on the same physical machine.8 Profiling a session based on a Figure 5-14 architecture was very simple, as there was a single server process for every client process and the client process could be easily associated with the end user.

Figure 5-14. The classic, though no longer commonly used, Oracle architecture with both the client and server process residing on the database server and communicating via SQL*Net. The user interface is typically a terminal or a terminal emulator. While network traffic is minimized, the user experience is bland, and the database server activity can easily reach capacity.

Figure 5-15 is very similar to Figure 5-14, yet the difference is significant. Figure 5-15 shows Oracle in what is traditionally called a single-task architecture. The server and client processes are linked into a single large executable. These single task executables actually have the letters st appended to the standard names to distinguish them from their two-task relatives. Operating in a two-task architecture, the client and server process communicate via SQL*Net. With a single-task architecture, because both the client and server components are part of the same executable, they communicate using function calls. When heavy communication is required between the server and client processes, a single-task architecture could boost performance by 10% to 50%. This made operations like an import much faster. Profiling a session was very simple, as there was a single client/server process associated with every end user.