Process Structure
A process is a "thread of control" or a mechanism in an operating system that can execute a
series of steps. Some operating systems use the terms job or task. A process normally has its own
private memory area in which it runs.
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
The Oracle's process architecture is designed to maximize performance.
Single-Process Oracle Instance
Single-process Oracle (also called single-user Oracle) is a database system in which all
Oracle code is executed by one process. Different processes are not used to separate
execution of the parts of Oracle and the client application program. Instead, all code of
Oracle and the single user's database application is executed by a single process.
Figure 9 - 2 shows a single-process Oracle instance. The single process executes all code
associated with the database application and Oracle.
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
Multiple-process Oracle (also called multi-user Oracle) uses several processes to execute
different parts of Oracle, and a separate process for each connected user. Each process in
a multiple-process Oracle instance performs a specific job. By dividing the work of Oracle
and database applications into several processes, multiple users and applications can
simultaneously connect to a single database instance while the system maintains
excellent performance. Most database systems are multi-user, because one of the primary
benefits of a database is managing data needed by multiple users at the same time.
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.
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
When a user runs an application program, such as a Pro*C program, or an Oracle tool, such
as Server Manager, Oracle creates a user process to run the user's application.
Oracle Processes
In multiple-process systems, two types of processes control Oracle: server processes and
background 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
To maximize performance and accommodate many users, a multi-process Oracle system uses some
additional Oracle processes called background processes.
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 illustrates each background process's interaction with the different
parts of an Oracle database, and the following sections describe each process.
The Parallel Server is not illustrated; see Oracle7 Parallel Server Concepts & Administration.
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
See "Locking Mechanisms" in Chapter 10 of Oracle7 Server Tuning.
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.
In the first two cases, DBWR writes the blocks on the dirty list to disk with a single
multiblock write. The number of blocks written in a multiblock write varies by operating system.
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
Note: LGWR writes synchronously to the active mirrored group of online redo log files.
If one of the files in the group is damaged or unavailable, LGWR can continue to write to
other files in the group (an error is also logged in the LGWR trace file and in the
system ALERT file). If all files in a group are damaged, or the group is unavailable because
it has not been archived, LGWR cannot continue to function. See "The Online Redo Log"
for more information about mirrored online redo logs and how LGWR functions in this
configuration.
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
Each server and background process can write to an associated trace file. When a process
detects an internal error, it dumps information about the error to its trace file. If an
internal error occurs and information is written to a trace file, the administrator should
contact Oracle support. See Oracle7 Server Messages.
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
Oracle uses the ALERT file to keep a log of these special operations as an alternative to
displaying such information on an operator's console (although many systems display
information on the console). If an operation is successful, a message is written in
the ALERT file as "completed" along with a timestamp.