Oracle7 Server Concepts

Variations in Oracle Configuration

All connected Oracle users must execute two modules of code to access an Oracle database instance:

application or Oracle tool A database user executes a database application (such as a precompiler program) or an Oracle tool (such as an Oracle Forms application), which issues SQL statements to an Oracle database.
Oracle server code Each user has some Oracle server code executing on his/her behalf, which interprets and processes the application's SQL statements.

In a multiple-process instance, the code for connected users can be configured in one of three variations:

For each user, both the database application and the Oracle server code are combined in a single user process.

For each user, the database application is run by a different process (a user process) than the one that executes the Oracle server code (a dedicated server process). This configuration is called the dedicated server architecture.

The database application is a different process (a user process) than the one that executes the Oracle server code. Furthermore, each server process that executes Oracle server code (a shared server process) can serve multiple user processes. This configuration is called the multi-threaded server architecture.

Additional Information: Some operating systems offer a choice of configurations; see your Oracle operating system-specific documentation for more details on your options. The following sections describe each variation in more detail.

Connections, Sessions, and User Processes

Before describing the variations in Oracle configurations, it is useful to introduce the terms "connection" and "session", which are related to the term "user process" (see "User Processes"

), but are very different in meaning.

A connection is a communication pathway between a user process and an Oracle instance. A communication pathway is established using available inter-process communication mechanisms (on a computer that executes both the user process and Oracle) or network software (when different computers execute the database application and Oracle, and communicate via a network).

A session is a specific connection of a user to an Oracle instance via a user process; for example, when a user starts SQL*Plus, the user must provide a valid username and password and then a session is established for the user. A session lasts from the time the user connects until the time the user disconnects (or exits the database application).

Multiple sessions can be created and concurrently exist for a single Oracle user; for example, a user with the username/password of SCOTT/TIGER can connect to the same Oracle instance several times using the same username.

When the multi-threaded server is not used, a server process is created on behalf of each user session; however, when the multi-threaded server is used, a single server process can be shared among many user sessions; each of the following sections describes the relationship of sessions and processes with respect to the configuration variations.

Oracle Using Combined User/Server Processes

Figure 9 - 7 illustrates one configuration of Oracle. Notice that in this configuration, the database application and the Oracle server code all run in the same process, termed a user process.

Figure 9 - 7. Oracle Using Combined User/Server Processes

This configuration of Oracle (sometimes called single-task Oracle) is only feasible in operating systems that can maintain a separation between the database application and the Oracle 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 and thus must have separate processes run application code from server code to prevent damage to Oracle by the application.

Note: The program interface is responsible for the separation and protection of the Oracle server code and is responsible for passing data between the database application and the Oracle user program. See "The Program Interface" for more information about this structure.

Only one Oracle 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 Oracle using a network (SQL*Net) interface.

Oracle Using Dedicated Server Processes

Figure 9 - 8 illustrates Oracle running on two computers using the dedicated server architecture.

Notice that in this type of system, a user process executes the database application on one machine and a server process executes the associated Oracle server on another machine. These two processes are separate, distinct processes. The separate server process created on behalf of each user process is called a dedicated server process (or shadow process) because this server process acts only on behalf of the associated user process.

In this configuration (sometimes called two-task Oracle), every user process connected to Oracle 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 (though it is inactive and may be paged out on some operating systems).

The dedicated server architecture of Oracle allows client applications being executed on client workstations to communicate with another computer running Oracle across a network. This is illustrated in Figure 9 - 8. However, this configuration of Oracle is also used if the same computer executes both the client application and the Oracle server code, but the host operating system cannot maintain the separation of the two programs if they were to be run in a single process. A common example of such an operating system is UNIX.

Figure 9 - 8. Oracle Using Dedicated Server Processes

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

If the system is configured so that the user process and the dedicated server process are run by the same computer, the program interface uses the host operating system's inter-process communication mechanism to perform its job.

If the user process and the dedicated server process are executed by different computers, the program interface also encompasses the communication mechanisms, such as the network software and SQL*Net, between the programs.

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

See "The Program Interface" for additional information about the program interface.

The Multi-Threaded Server

The multi-threaded server configuration allows many user processes to share very few server processes. Without the 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. With the multi-threaded server configuration, many user processes connect to a dispatcher process. The dispatcher 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.

Contrasting Dedicated Server Processes and Shared 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 processing as many dedicated server processes. Also, the amount of memory required for each user is relatively small. Because less memory and process management are required, more users can be supported.

An Overview of the Multi-Threaded Server Architecture

The following types of processes are needed in a system using the multi-threaded server architecture:

a network listener process that connects user processes to dispatchers and dedicated servers (this process is part of SQL*Net, not Oracle).

one or more dispatcher processes

one or more shared server processes

The network listener process waits for incoming connection requests and determines if each user process can use a shared server process. If so, the listener gives the user process the address of a dispatcher process. If the user process requests a dedicated server, the listener process creates a dedicated server process and connects the user process to it. (At least one dispatcher process must be configured and started per network protocol that the database clients will use.)

Note: To use shared servers, a user process must connect through SQL*Net, even if the user process is on the same machine as the Oracle instance.

A request from a user is a single program interface call that is part of the user's SQL statement. When a user makes a call, its dispatcher places the request on the request queue in the SGA, where it is picked up by the next available shared server process. The shared server processes make all the necessary calls to the database to complete each user process's request. When the server completes the request, the server returns the results to the response queue of the dispatcher that the user is connected to the SGA. The dispatcher then returns the completed request to the user process.

In the order entry system example, each clerk's user process connects to a dispatcher; each request made by a clerk is sent to a dispatcher, which places the request in the request queue. The next available shared server process picks up the request, services it, and puts the response in the response queue. When a clerk's request is completed, the clerk remains connected to the dispatcher, but the shared server process that processed the request is released and available for other requests. While one clerk is talking to a customer, not making a request to the database, another clerk can use the same shared server process.

Figure 9 - 9 illustrates how user processes communicate with the dispatcher across the two-task interface and how the dispatcher communicates users' requests to shared server processes.

Figure 9 - 9. The Oracle Multi-Threaded Server Configuration and Shared Server Processes

Shared Server Processes

Shared server processes and dedicated server processes provide the same functionality, except shared server processes are not associated with a specific user process. Instead, a shared server process serves any client request in the multi-threaded server configuration.

The PGA of a shared server process does not contain user-related data; such information needs to be accessible to all shared server processes. The PGA of a shared server process contains only stack space and process-specific variables. "Program Global Area (PGA)" provides more information about the content of a PGA in different types of instance configurations.

All session-related information is contained in the SGA. Each shared server process needs to be able to access all sessions' data spaces so that any server can handle requests from any session. Space is allocated in the SGA for each session's data space. You can limit the amount of space that a session can allocate by setting the resource limit PRIVATE_SGA to the desired amount of space in the user's profile. See Chapter 17, "Database Access," for more information about resource limits and profiles.

Oracle dynamically adjusts the number of shared server processes based on the length of the request queue. The number of shared server processes that can be created ranges between the initialization parameters MTS_SERVERS and MTS_MAX_SERVERS.

Dispatcher Request and Response Queues

The request queue is in the SGA and is common to all dispatcher processes of an instance. The shared server processes check the common request queue for new requests, picking up new requests on a first-in-first-out basis. One shared server process picks up one request in the queue and makes all necessary calls to the database to complete that request. The shared server process then places the response on the calling dispatcher's response queue. Each dispatcher has its own response queue in the SGA and each dispatcher is responsible for sending completed requests back to the appropriate user process.

Artificial Deadlocks

With a limited number of shared server processes, the possibility of an "artificial" deadlock can arise. An artificial deadlock can occur in the following situation:

1. One user acquires an exclusive lock on a resource by issuing a SELECT statement with the FOR UPDATE clause or LOCK TABLE statement.

2. The shared server process used to process the locking request is released once the statement completes.

3. Other users attempt to access the locked resource. Each shared server process is bound to the user process it is serving until the necessary locked resource becomes available. Eventually, all shared servers may be bound to users waiting for locked resources.

4. The original user attempts to submit a new request (such as a COMMIT or ROLLBACK statement) to release the previously acquired lock, but cannot because all shared server processes are currently being used. When Oracle detects an artificial deadlock, new shared server processes are automatically created as needed until the original user submits a request that releases the locked resources causing the artificial deadlocks. If the maximum number of shared server processes (as specified by the MTS_MAX_SERVERS parameter) have been started, the database administrator must manually resolve the deadlock by disconnecting a user. This releases a shared server process, resolving the artificial deadlock.

If artificial deadlocks occur too frequently on your system, you should increase the value of MTS_MAX_SERVERS.

Restricted Operations of the Multi-Threaded Server

Certain administrative activities cannot be performed while connected to a dispatcher process, including shutting down or starting an instance and media recovery. An error message is issued if you attempt to perform these activities while connected to a dispatcher process.

These activities are typically performed when connected as INTERNAL. When you want to connect as INTERNAL in system configured with multi-threaded servers, you must state in your connect string that you want to use a dedicated server process instead of a dispatcher process (SRVR=DEDICATED).

Additional Information: See your Oracle operating system-specific documentation or SQL*Net documentation for the proper connect string syntax.

application or Oracle tool	A database user executes a database application (such as a precompiler program) or an Oracle tool (such as an Oracle Forms application), which issues SQL statements to an Oracle database.
Oracle server code	Each user has some Oracle server code executing on his/her behalf, which interprets and processes the application's SQL statements.