Process Structure

The process structure of Oracle is important because it defines how multiple activities can occur and how they are accomplished. For example, two goals of a process structure might be

• to simulate a private environment for multiple processes to work simultaneously, as though each process has its own private environment

• to allow multiple processes to share computer resources, which each process needs, but no process needs for long periods of time

Single-Process Oracle Instance

Figure 9 - 2 shows a single-process Oracle instance. The single process executes all code associated with the database application and Oracle.

Figure 9 - 2. A Single-Process Oracle Instance

Only one user can access an Oracle instance in a single-process environment; multiple users cannot access the database concurrently. For example, Oracle running under the MS-DOS operating system on a PC can only be accessed by a single user because MS-DOS is not capable of running multiple processes.

Multiple-Process Oracle Instance

Figure 9 - 3 illustrates a multiple-process Oracle instance. Each connected user has a separate user process and several background processes are used to execute Oracle. This figure might represent multiple concurrent users running an application on the same machine as Oracle; this particular configuration is usually on a mainframe or minicomputer.

Figure 9 - 3. A Multiple-Process Oracle Instance

In a multiple-process system, processes can be categorized into two groups: user processes and Oracle processes. The following sections explain these classes of processes.

User Processes

Oracle Processes

Oracle creates server processes to handle the requests of user processes connected to the instance. Often, when the application and Oracle operate on the same machine rather than over a network, a user process and its corresponding server process are combined into a single process to reduce system overhead. However, when the application and Oracle operate on different machines, a user process communicates with Oracle via a separate server process. See "Variations in Oracle Configuration" for more information.

Server processes (or the server portion of combined user/server processes) created on behalf of each user's application may perform one or more of the following:

• parse and execute SQL statements issued via the application

• read necessary data blocks from disk (datafiles) into the shared database buffers of the SGA, if the blocks are not already present in the SGA

• return results in such a way that the application can process the information

Additional Information: On many operating systems, background processes are created automatically when an instance is started. On other operating systems, the server processes are created as a part of the Oracle installation. See your Oracle operating system-specific documentation for details on how these processes are created.

An Oracle instance may have many background processes; not all are always present. The background processes in an Oracle instance include the following:

• Database Writer (DBWR)

• Log Writer (LGWR)

• Checkpoint (CKPT)

• System Monitor (SMON)

• Process Monitor (PMON)

• Archiver (ARCH)

• Recoverer (RECO)

• Lock (LCKn)

• Snapshot Refresh (SNPn)

• Dispatcher (Dnnn)

• Server (Snnn)

Figure 9 - 4. The Background Processes of a Multiple-Process Oracle Instance

Database Writer (DBWR) Database Writer process (DBWR) writes buffers to datafiles. DBWR is an Oracle background process responsible for buffer cache management. For more information about the database buffer cache, see "The Database Buffer Cache" .

When a buffer in the buffer cache is modified, it is marked "dirty". The primary job of the DBWR process is to keep the buffer cache "clean" by writing dirty buffers to disk. As buffers are filled and dirtied by user processes, the number of free buffers diminishes. If the number of free buffers drops too low, user processes that must read blocks from disk into the cache are not able to find free buffers. DBWR manages the buffer cache so that user processes can always find free buffers.

An LRU (least recently used) algorithm keeps the most recently used data blocks in memory and thus minimizes I/O. The database writer process (DBWR) keeps blocks that are used often, for example, blocks that are part of frequently accessed small tables or indexes, in the cache so that they do not need to be read in again from disk. To make room in the buffer cache for other blocks, DBWR removes blocks that are accessed infrequently (for example, blocks that are part of very large tables or leaf blocks from very large indexes) from the system global area (SGA). For information about leaf blocks, see "The Internal Structure of Indexes" .

The LRU scheme causes more frequently accessed blocks to stay in the buffer cache so that when a buffer is written to disk, it is unlikely to contain data that may be useful soon. However, if the DBWR process becomes too active, it may write blocks to disk that are about to be needed again.

The buffer cache has multiple LRU latches. Latches are automatic internal locks that protect shared data structures. The initialization parameter DB_BLOCK_LRU_LATCHES controls how many latches are configured and by default is set to the number of CPUs on your system. This is usually a good value to reduce latch contention for the DBWR processes, thus improving performance.

For More Information

The DBWR process writes dirty buffers to disk under the following conditions:

• When a server process moves a buffer to the dirty list and discovers that the dirty list has reached a threshold length, the server process signals DBWR to write.

• When a server process searches a threshold limit of buffers in the LRU list without finding a free buffer, it stops searching and signals DBWR to write (because not enough free buffers are available and DBWR must make room for more).

• When a time-out occurs (every three seconds), DBWR signals itself.

• When a checkpoint occurs, the Log Writer process (LGWR) signals DBWR.

A time-out occurs if DBWR is inactive for three seconds. In this case, DBWR searches a specified number of buffers on the LRU list and writes any dirty buffers that it finds to disk. Whenever a time-out occurs, DBWR searches a new set of buffers. If the database is idle, DBWR eventually writes the entire buffer cache to disk.

When a checkpoint occurs, the Log Writer process (LGWR) specifies a list of modified buffers that must be written to disk. DBWR writes the specified buffers to disk. For more information about checkpoints, see "Checkpoints" .

Additional Information: On some platforms, an instance can have multiple DBWRs. In such a case, if one DBWR blocks during a write to one disk, the others can continue writing to other disks. The parameter DB_WRITERS controls the number of DBWR processes. See your Oracle operating system-specific documentation for information about DBWR on your platform.

For more information about DBWR and how to monitor and tune the performance of DBWR, see the Oracle7 Server Administrator's Guide and Oracle7 Server Tuning.

Log Writer (LGWR) The Log Writer process (LGWR) writes the redo log buffer to a redo log file on disk. LGWR is an Oracle background process responsible for redo log buffer management. LGWR writes all redo entries that have been copied into the buffer since the last time it wrote. LGWR writes one contiguous portion of the buffer to disk. LGWR writes

• a commit record when a user process commits a transaction

• redo buffers every three seconds

• redo buffers when the redo log buffer is one-third full

• redo buffers when the DBWR process writes modified buffers to disk

The redo log buffer (see "The Redo Log Buffer" ) is a circular buffer; when LGWR writes redo entries from the redo log buffer to a redo log file, server processes can then copy new entries over the entries in the redo log buffer that have been written to disk. LGWR normally writes fast enough to ensure that space is always available in the buffer for new entries, even when access to the redo log is heavy.

Note: Sometimes, if more buffer space is needed, LGWR writes redo log entries before a transaction is committed. These entries become permanent only if the transaction is later committed.

Oracle uses a "fast commit" mechanism; when a user issues a COMMIT statement, LGWR puts a commit record immediately in the redo log buffer, but the corresponding data buffer changes are deferred until it is more efficient to write them to the datafiles. The atomic write of the redo entry containing the commit record for a transaction is the single event that determines the transaction has committed (then Oracle returns a success code to the committing transaction).

When a user commits a transaction, the transaction is assigned a system change number (SCN), which Oracle records along with the transaction's redo entries in the redo log. SCNs are recorded in the redo log so that recovery operations can be synchronized in Parallel Server configurations and distributed databases. See Oracle7 Parallel Server Concepts & Administration and the Oracle7 Server Administrator's Guide for more information about SCNs and how they are used.

In times of high activity, LGWR may write to the online redo log file using group commits. For example, assume that a user commits a transaction -- LGWR must write the transaction's redo entries to disk. As this happens, other users issue a COMMIT statement. However, LGWR cannot write to the online redo log file to commit these transactions until it has completed its previous write operation. After the first transaction's entries are written to the online redo log file, the entire list of redo entries of waiting transactions (not yet committed) can be written to disk in one operation, requiring less I/O than would transaction entries handled individually. Therefore, Oracle minimizes disk I/O and maximizes performance of LGWR. If requests to commit continue at a high rate, then every write (by LGWR) from the redo log buffer may contain multiple commit records, averaging less than one write per COMMIT.

If the CKPT background process is not present, LGWR is also responsible for recording checkpoints as they occur in every datafile's header. See "Checkpoint (CKPT)" below for more information about this background process.

Checkpoint (CKPT) When a checkpoint occurs, Oracle must update the headers of all datafiles to indicate the checkpoint. In normal situations, this job is performed by LGWR. However, if checkpoints significantly degrade system performance (usually, when there are many datafiles), you can enable the Checkpoint process (CKPT) to separate the work of performing a checkpoint from other work performed by LGWR, the Log Writer process (LGWR).

For most applications, the CKPT process is not necessary. If your database has many datafiles and the performance of the LGWR process is reduced significantly during checkpoints, you may want to enable the CKPT process.

The CKPT process does not write blocks to disk; DBWR always performs that work. The statistic DBWR checkpoints displayed by the System_Statistics monitor in Server Manager indicates the number of checkpoint messages completed, regardless of whether the CKPT process is enabled or not. See the Oracle7 Server Administrator's Guide for information about the effects of changing the checkpoint interval.

The initialization parameter CHECKPOINT_PROCESS enables and disables the CKPT process; its default is FALSE.

Note: See Oracle7 Parallel Server Concepts & Administration for additional information about CKPT in an Oracle Parallel Sever.

System Monitor (SMON) The System Monitor process (SMON) performs instance recovery at instance start up. SMON is also responsible for cleaning up temporary segments that are no longer in use; it also coalesces contiguous free extents to make larger blocks of free space available. In a Parallel Server environment, SMON performs instance recovery for a failed CPU or instance; see Oracle7 Parallel Server Concepts & Administration for more information about SMON in an Oracle Parallel Server.

SMON "wakes up" regularly to check whether it is needed. Other processes can call SMON if they detect a need for SMON to wake up.

Process Monitor (PMON) The Process Monitor (PMON) performs process recovery when a user process fails. PMON is responsible for cleaning up the cache and freeing resources that the process was using. For example, it resets the status of the active transaction table, releases locks, and removes the process ID from the list of active processes.

PMON also periodically checks the status of dispatcher and server processes, and restarts any that have died (but not any that Oracle has killed intentionally).

Like SMON, PMON "wakes up" regularly to check whether it is needed, and can be called if another process detects the need for it.

Recoverer (RECO) The Recoverer process (RECO) is a process used with the distributed option that automatically resolves failures involving distributed transactions. The RECO background process of a node automatically connects to other databases involved in an in-doubt distributed transaction. When the RECO process re-establishes a connection between involved database servers, it automatically resolves all in-doubt transactions.

The RECO process automatically removes rows corresponding to any resolved in-doubt transactions from each database's pending transaction table.

If the RECO background process attempts to establish communication with a remote server, and the remote server is not available or the network connection has not been re-established, RECO automatically tries to connect again after a timed interval. However, RECO waits an increasing amount of time (growing exponentially) before it attempts another connection.

For more information about distributed transaction recovery, see Oracle7 Server Distributed Systems, Volume I.

The RECO background process of an instance is only present if the system permits distributed transactions and if the DISTRIBUTED_TRANSACTIONS parameter is greater than zero. If this parameter is zero, RECO is not created during instance startup.

Archiver (ARCH) The Archiver process (ARCH) copies online redo log files to a designated storage device once they become full. ARCH is present only when the redo log is used in ARCHIVELOG mode and automatic archiving is enabled. For information on archiving the online redo log, see Chapter 22, "Recovery Structures".

Additional Information: Details of using ARCH are operating system specific; for more information, see Oracle operating system-specific documentation.

Lock (LCKn) With the Parallel Server option, up to ten Lock processes (LCK0, . . ., LCK9) provide inter-instance locking. However, a single LCK process (LCK0) is sufficient for most Parallel Server systems. See Oracle7 Parallel Server Concepts & Administration for more information about this background process.

Snapshot Refresh (SNPn) With the distributed option, up to ten Snapshot Refresh processes (SNP0, ..., SNP9) can automatically refresh table snapshots. These processes wake up periodically and refresh any snapshots that are scheduled to be automatically refreshed. If more than one Snapshot Refresh process is used, the processes share the task of refreshing snapshots.

Dispatcher Processes (Dnnn) The Dispatcher processes allow user processes to share a limited number of server processes. Without a dispatcher, each user process requires one dedicated server process. However, with the multi-threaded server, fewer shared server processes are required for the same number of users. Therefore, in a system with many users, the multi-threaded server can support a greater number of users, particularly in client-server environments where the client application and server operate on different machines.

You can create multiple dispatcher processes for a single database instance; at least one dispatcher must be created for each network protocol used with Oracle. The database administrator should start an optimal number of dispatcher processes depending on the operating system limitation on the number of connections per process, and can add and remove dispatcher processes while the instance runs.

Note: The multi-threaded server requires SQL*Net Version 2 or later. Each user process that connects to a dispatcher must do so through SQL*Net, even if both processes are running on the same machine.

In a multi-threaded server configuration, a network listener process waits for connection requests from client applications, and routes each to a dispatcher process. If it cannot connect a client application to a dispatcher, the listener process starts a dedicated server process, and connects the client application to the dedicated server. This listener process is not part of an Oracle instance; rather, it is part of the networking processes that work with Oracle. See your SQL*Net documentation for more information about the network listener.

When an instance starts, the listener opens and establishes a communication pathway through which users connect to Oracle. Then, each dispatcher gives the listener an address at which the dispatcher listens for connection requests. When a user process makes a connection request, the listener process examines the request and determines if the user can use a dispatcher. If so, the listener process returns the address of the dispatcher process with the lightest load and the user process directly connects to the dispatcher.

Some user processes cannot communicate with the dispatcher (such as users connected using pre-Version 2 SQL*Net) and the network listener process cannot connect such users to a dispatcher. In this case, the listener creates a dedicated server and establishes an appropriate connection.

Trace Files, the ALERT File, and Background Processes

All filenames of trace files associated with a background process contain the name of the process that generated the trace file. The one exception to this is trace files generated by Snapshot Refresh processes.

Trace file information can also provide information for tuning applications or an instance. Background processes always write to a trace file when appropriate. However, trace files are written on behalf of server processes (in addition to being written to when there is an internal error) only if the initialization parameter SQL_TRACE is set to TRUE. Regardless of the current value for this parameter, each session can enable or disable trace logging on behalf of the associated server process by using the SQL command ALTER SESSION with the SQL_TRACE parameter. For example, the following statement enables writing to a trace file for the session:

ALTER SESSION SET SQL_TRACE = TRUE; 

Each database also has an ALERT file. The ALERT file of a database is a chronological log of messages and errors, including

• all internal errors (ORA-600), block corruption errors (ORA-1578), and deadlock errors (ORA-60) that occur

• administrative operations, such as CREATE/ALTER/DROP DATABASE/TABLESPACE/ROLLBACK SEGMENT SQL statements and STARTUP, SHUTDOWN, ARCHIVE LOG, and RECOVER Server Manager statements

• several messages and errors relating to the functions of shared server and dispatcher processes

• errors during the automatic refresh of a snapshot