Oracle System Architecture Processes

DBWn – Database Writer

Note that Oracle changed the naming format of the DBWR process to DBWn as of Oracle8, where n can be a number from 0 through 9. If you use multiple DB writer processes, you should note that the db_writers parameter has changed to db_writer_processes.

The DBWn (Dirty Buffer Writer) process writes modified (or dirty) blocks from the database buffer cache to the disk files. Blocks are not written on commit, only the rollback segment segments and header are affected by a commit. In general, DBWn writes only when more data needs to be read into the system global area and too few database buffers are free. The least recently used data is written to the datafiles first. DBWR's entire purpose in life is to manage the database buffer cache to that the server processes can always find free buffers.

As of Oracle 7.3, if blocks have their lock bit set (that is, they were modified by a transaction) then as they are written out of the cache, DBWn resets their lock bits back to unlocked status. In versions prior to 7.3 the blocks were written as-is and the next process to read them reset the lock bits. A dirty buffer is any buffer that has had any of its bits twiddled. Even if only the lock bit is turned on and no other changes are performed the block must be re-written to disk. Writes are always deferred if needed to optimize system I/O.

It's important to note that DBWn only writes. It does no reading other than from cache; the dedicated and MTS serer processes do all reading of disks. It is the only process that writes changed blocks from the database buffer cache to disk.

DBWn behavior is controlled by initialization parameters. The initialization parameter ASYNC_WRITE tells DBWn to enable asynchronous writing to database files on systems which allow this to be switchable. On systems where asynchronous writes are the normal mode, ASYNC_WRITE is not required to be set.

LGWR – Log Writer

The LGWR (Log Writer) process writes out the redo buffer to the redo logs on a commit. At specific times, all modified database buffers in the system global area are written to the datafiles by DBWR; this event is called a checkpoint. The LGWR process is responsible for signaling DBWR at checkpoints and updating all the datafiles and control files of the database to indicate the most recent checkpoint.

SMON – System Monitor

The SMON (Server Monitor) process monitors the Oracle instance, recovers temporary segment space when it is no longer needed. It coalesces contiguous areas of freespace in database tablespaces where the default storage parameter, PCTINCREASE, is not set to zero, and recovers dead transactions skipped during crash and instance recovery because of file-read or offline errors. These transactions are eventually recovered by SMON when the tablespace or file is brought back online. If SMON dies, the instance will crash requiring instance recovery on restart.

PMON – Process Monitor

The PMON (Process Monitor) process cleans up failed transactions. This clean up involves cleaning out cache entries, releasing locks and freeing other process resources. If MTS is being used, PMON watches for dead dispatcher and server processes and restarts them as needed. If PMON dies, the instance will crash requiring instance recovery on startup. In the situation where an instance crashed and is then restarted, PMON will rollback any uncommitted transactions using the information in the rollback segments.

ARCH – Archiver Process

The ARCH (Archiver) process is responsible for copying filled redo log files to the archive log destination. The ARCH process is only present if archive logging is enabled for the instance. If the archive log destination is full, the archive log process will silently hang, only reporting a problem to new logins and the alert log. No redo log will be reused until it has been archived if archive logging is in effect for the database. The ARCHIVE_LOG_START parameter must be set to TRUE and the ARCHIVELOG mode must be set in the database for archive logging to be in effect. If only the ARCHIVELOG mode is set via the ALTER DATABASE command, database processing will continue until all available redo logs are filled, and then Oracle will hang with an error in the alert log indicating that all online redo logs need archiving. If the ARCH process abnormally terminates, the database will continue operation until all online redo logs are filled before it will hang.

RECO – Distributed Transaction Recoverer

The RECO process recovers failed distributed transactions and is only present if the distributed database option is installed in the database system. The RECO process is started only if the DISTRIBUTED_TRANSACTIONS initialization parameter is set to a value greater than zero. For databases with the distributed option, the default for DISTRIBUTED_TRANSACTIONS is 32, so if you want to disable the RECO process, you must explicitly set this parameter to zero in the parameter file.

LCKn – Lock Process

This process is used for inter-instance locking in a parallel server environment. These multiple processes, named LCK0 through LCK9, are set via the GC_LCK_PROCS INIT.ORA parameter.

Dnnnn and Snnnn Process(es)

The Dnnnn (Dispatcher) process(es) (nnnn is a sequential number) distribute instance attachments to Snnnn (server) processes. Snnnn (server) processes (nnnn is a sequential number) take the place of dedicated servers for user connection in multi-threaded server enabled systems (MTS). Dnnnn and Snnnn processes are only present in MTS systems.

The Dnnnn and Snnnn processes are controlled by the MTS_DISPATCHERS, MTS_MAX_DISPATCHERS, MTS_SERVERS and MTS_MAX_SERVERS initialization parameters. The MTS_DISPATCHERS and MTS_SERVERS parameters set the minimum number of Dnnnn and Snnnn processes created at instance startup. The MTS_MAX_DISPATCHERS and MTS_MAX_SERVERS parameters set the maximum number of Dnnnn and Snnnn processes allowed to be automatically started as needed.

In an MTS system the SQLNET listener process determines if a user connection should be dedicated or should use a shared server process. If the listener determines that a shared connection is appropriate, it gives the user process the address of a dispatcher process.

In a dedicated server environment both the D and S processes are combined and a single process is started for each user; this single process is simply called a server process. This dedicated environment is also referred to as being a single-tasked or combined user and server process environment.

LISTENER

If you are running TCP/IP, this process will be running as well (only one per node).

CKPTxx

If the CKPT process (optional in Oracle 7.x and mandatory in ORACLE8) is present the checkpoint responsibilities of LGWR are assumed by the CKPT process. The CKPT process is controlled by the CHECKPOINT_PROCESS initialization parameter in versions less than 8.0. The LGWR process also allows for recovery of committed data in the database buffer cache at the time of an instance failure.

Checkpoints help to reduce the time required to recover an instance. Checkpoints cause DBWR to write all of the blocks that have been changed since the last checkpoint to the datafile. The datafile headers and control files will also be updated to record the checkpoint.

The CKPT background process may be added to split the LGWR functions of signaling a checkpoint and copying the redo log entries. CKPT is enabled by setting the INIT.ORA parameter CHECKPOINT_PROCESS to TRUE.

If the LGWR or CKPT process needs a file that the DBWR process is checkpointing, it waits until DBWR completes the checkpoint operation.

SNPnn

The SNPnm (Snapshot) process (where n is an integer) was initially used strictly for snapshot processing. When job queues were added to the Oracle system, the SNP rpocesses were also tasked with checking and executing jobs for the job queues. A failed snapshot process may inhibit job queue or snapshot processing and will generate a trace file, but otherwise will not affect Oracle instance operation. Snapshot processes (or job queue processes) failure will result in an alert log entry.

The job queue processes are controlled by the JOB_QUEUE_PROCESSES, JOB_QUEUE_INTERVAL and JOB_QUEUE_KEEP_CONNECTIONS (in some installations these may begin with SNAPSHOT instead of JOB) initialization parameters. The JOB_QUEUE_PROCESSES sets the number of SNP processes created at instance startup. The JOB_QUEUE_INTERVAL parameter sets the wakeup interval for the processes (how often they wakeup and check the job and snapshot queue tables). The JOB_QUEUE_KEEP_CONNECTIONS initialization parameter tells the snapshot refresh process to keep database links open between process runs.

The QMNnn Process

Associated with Oracle's advanced queuing, this process is called the queue manager process. To enable this optional process, set the init.ora parameter aq_tm_processes. This parameter can be set to only 0 or 1. The process monitors the Oracle advanced queuing message queues.

On certain platforms, there are problems enabling the QMN process. Oracle has created a workaround document to deal with this issue. Reference Oracle bug 638191 if you have a problem starting this process. Some Oracle documentation reports that you can start up to 10 of these processes, but this is not the case in Oracle8.0.5, where only one process may be started.

EXTPROC

These are the callout queues, there is one for each session performing call outs. Currently these processes are not multi-threaded. As of the 8.0.2 beta this was not working with environments where multi-threaded server was enabled. This functionality has been promised in 8.0.3.

ARCHMON – Archive Monitor

On a Unix system, this additional process may be present. This process monitors the archive process and writes the redo logs to the archives. It will require a dedicated window or terminal on BSD systems.

Pnnnn Processes

Pnnnn (Parallel Query Slave) processes (nnnn is a sequential number) are started and stopped by the parallel query server. A single parallel query can result in dozens of Pnnnn processes depending on table size and number of processors and disks as well as initialization parameters. Loss of a Pnnnn process may result in a failed query but otherwise shouldn't affect instance operations. On some Oracle versions, abnormal or forced termination of a Pnnnn process can result in instance termination; this is a known Oracle bug.

The Pnnnn processes are controlled by the initialization parameters PARALLEL_MIN_SERVERS, PARALLEL_MAX_SERVERS, PARALLEL_MIN_PERCENT and PARALLEL_SERVER_IDLE_TIME. The PARALLEL_MIN_SERVERS parameter sets the minimum number of parallel query slave processes to start at instance startup. The PARALLEL_MAX_SERVERS parameter is used to control the maximum number of parallel query servers that can be started for the entire instance. The PARALLEL_MIN_PERCENT parameter determines the minimum number of parallel query slave processes that must be available for a query to be processed in parallel. The PARALLEL_SERVER_IDLE_TIME parameter sets the number of seconds a slave process can be idle before it is removed.

MMON

MMON is the acronym for Memory Monitor, a new process introduced in Oracle Database 10g associated with the Automatic Workload Repository (AWR). AWR gets the necessary statistics for automatic problem detaction and tuning with the help of MMON. MMON writes out the required statistics for AWR on a regularly scheduled basis to disk. MMON performs various manageability related tasks like issuing an alert whenever a given metrics violates given threshold values, taking snapshots while spawning additional MMON slave processes and capturing statics values for SQL objects recently modified.

MMNL

Memory Monitor Light (MMNL) is another new process in Oracle Database 10g, which assists the AWR to write the full statistics buffers to disk on an as-needed basis. MMNL captures session history and performs metrics computations.

MMAN

This is used from internal database tasks.

RBAL

RBAL coordinates rebalance activities on disk groups in an ASM instance and performs global opens on ASM disks. RBAL is an ASM related process to perform the rebalancing of disks controlled by an ASM instance.

ORBn

ORBn performs actual data extent movement for rebalance in an ASM instance and may vary from instance to instance from ORB0 to ….

OSMB

This process is present on a database instance and accountable for communication between the database instance and ASM managed disk groups.

RVWR

Recovery Writer (RVWR) is a new background process introduced in Oracle Database 10g to write flashback logs with pre-images of data blocks to disk. The location can be specified by the db_recovery_file_dest parameter.

ASMB

ASM stands for Automatic Storage Management. ASMB is the background process used to pass the necessary information to and from the Cluster Synchronization Services to manage the disk resources used by ASM. ASMB also updates statistics and maintains the heartbeat mechanism for storage management

ARBx

The RBAL process to do the actual rebalancing operations on ASM controlled disk recources uses ARBx processes. The total number of ARBx processes started is controlled by the asm_power_limit_parameter.

CTWR

Change Tracking Writer (CTWR) is a new process that works with the new block changed tracking features in Oracle Database 10g. Block Change Tracking is used to optimize incremental backups. A new file is introduced. The CTWR background process tracks changed blocks as redo is generated. RMAN database backups automatically use the change-tracking file. You can use the V$BLOCK_CHANGE_TRACKING view to monitor the usage