Oracle7 Server Distributed Systems Volume I: Distributed Data

Contents Index Home Previous Next

Server Configurations

Oracle7 Server can be configured in three ways, as a:

Dedicated Server

Figure 1 - 2 illustrates Oracle7 running on two computers using the dedicated server architecture.

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.

Dedicated Server Process

The separate server process created for each user process is called a dedicated server process (formerly referred to as "shadow process") because this server process acts only on behalf of the associated user process. In this configuration (sometimes called two-task Oracle7), every user process connected to Oracle7 has a corresponding dedicated server process.

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.

The Program Interface

The program interface allows communication between the two programs. In the dedicated server configuration, communication between the user and server processes occurs using different mechanisms:

Additional Information: These communications links are operating system- and installation-dependent; see your Oracle operating system-specific documentation and Understanding SQL*Net for more information.

Additional Information: See "The Program Interface" in Chapter 1 of the Oracle7 Server Concepts manual for additional information.

Combined User/Server Process

Figure 1 - 3 illustrates the combined user/server configuration of Oracle7. Notice that in this configuration, the database application and the Oracle7 Server code all run in the same process, termed a user process.

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.

Multi-Threaded Server

The multi-threaded server (MTS) configuration (or "shared server" configuration) allows many user processes to share very few server processes.

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" [*].

Contrasting Dedicated Server Processes and Multi-Threaded Server Processes

Consider an order entry system with dedicated server processes. A customer places an order as a clerk enters the order into the database. For most of the transaction, the clerk is on the telephone talking to the customer, and the server process dedicated to the clerk's user process remains idle. The server process is not needed during most of the transaction, and the system is slower for other clerks entering orders.

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.


Contents Index Home Previous Next