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.

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.