Figure 1 - 2. Oracle7 Using Dedicated Server Processes
Notice that, in this type of system, the database application is executed by a user process on one machine, and the associated Oracle7 Server code is executed by a server process on another machine. These two processes are separate, distinct processes.
Therefore, there is a one-to-one ratio between the number of user processes and server processes in this configuration. Even when the user is not actively making a database request, the dedicated server process remains (although it is inactive and may be paged out on some operating systems).
The dedicated server architecture of Oracle7 allows client applications being executed on client workstations to communicate with another computer running Oracle7 across a network.
This configuration of Oracle7 is also used if the same computer executes both the client application and Oracle7 Server code and, the host operating system cannot maintain the separation of the two programs if they are run in a single process. A common example of such an operating system is UNIX.
Additional Information: See "The Program Interface" in Chapter 1 of the Oracle7 Server Concepts manual for additional information.
Figure 1 - 3. Oracle7 Using Combined User/Server Processes
This configuration of Oracle7 (sometimes called single-task Oracle7) is only feasible in operating systems that can maintain a separation between the database application and the Oracle7 code in a single process (such as on the VAX VMS operating system). This separation is required for data integrity and privacy. Some operating systems, such as UNIX, cannot provide this separation, so they must have separate processes run application code and server code to prevent damage to Oracle7 by the application.
Note: The program interface is responsible for the separation and protection of Oracle7 Server code and is responsible for passing data between the database application and the Oracle7 user program. For more information about the program interface, see the Oracle7 Server Concepts manual.
Only one Oracle7 connection is allowed at any time by a process using the above configuration. However, in a user-written program, it is possible to maintain this type of connection while concurrently connecting to Oracle7 using a network (SQL*Net) interface.
In a non-multi-threaded server configuration, each user process requires its own dedicated server process; a new server process is created for each client requesting a connection. A dedicated server process remains associated to the user process for the remainder of the connection.
In a multi-threaded server configuration, client processes connect to a SQL*Net listener process which provides the network address of a dispatcher process to the client. The client then connects to this dispatcher process. Requests for services from the client are placed in a request queue where they wait for the next available server process. Results are returned to the client by the dispatcher process. In this way, the listener routes client requests to the next available shared server process.
The advantage of the multi-threaded server configuration is that system overhead is reduced, so the number of users that can be supported is increased. For more information about the multi-threaded server and the network listener, see "How SQL*Net Establishes Connections to the Multi-Threaded Server" . and "SQL*Net and the Network Listener" .
The multi-threaded server configuration eliminates the need for a dedicated server process for each connection. A small number of shared server processes can perform the same amount of work, and the memory required for each user is relatively small. Because less memory and process management are required, more users can be supported.