Background Processes
Background Processes
Figure. 4.6 shows various background processes (as listed following the figure) that are spawned to
execute the database processing.
SMON - System Monitor process recovers after instance failure and monitors temporary segments
and extents. SMON in a non-failed instance can also perform failed instance recovery for other
failed RAC instance.
PMON - Process Monitor process recovers failed process resources. If MTS (also called Shared
Server Architecture) is being utilized. PMON monitors and restarts any failed dispatcher or server
processes. In RAC, PMON’s role as service registration agent is particularly important.
DBWR - Database Writer or Dirty Buffer Writer process is responsible for writing dirty buffers
from the database block cache to the database data files. Generally, DBWR only writes blocks back
to the data files on commit, or when the cache is full and space has to be made for more blocks. The
possible multiple DBWR processes in RAC must be coordinated through the locking and global
cache processes to ensure efficient processing is accomplished.
LGWR - Log Writer process is responsible for writing the log buffers out to the redo logs. I n RAC,
each RAC instance has its own LGWR process that maintains that instance’s thread of redo logs.
ARCH - (Optional) Archive process writes filled redo logs to the archive log location(s). In RAC, the
various ARCH processes can be utilized to ensure that copies of the archived redo logs for each
instance are available to the other instances in the RAC setup should they be needed for recovery.
CKPT - Checkpoint process writes checkpoint information to control files and data file headers.
Pnnn - (Optional) Parallel Query Slaves are started and stopped as needed to participate in parallel
query operations.
CQJ0 - Job queue controller process wakes up periodically and checks the job log. If a job is due, it
spawns Jnnn processes to handle jobs.
Jnnn - (Optional) Job processes used by the Oracle9i job queues to process internal Oracle9i jobs.
The CQJ0 process controls it automatically.
QMN - (Optional) Advanced Queuing process is used to control the advanced queuing jobs.
Snnn - (Optional) Pre-spawned shared server processes are used by the multi-threaded server
(MTS) process to handle connection requests from users, and act as connection pools for user
processes. These user processes also handle disk reads from database datafiles into the database
block buffers.
Dnnn - (Optional) Dispatcher process for shared server (MTS) - It accepts connection requests and
portions them out to the pre-spawned server processes.
MMON – This process performs various manageability-related background tasks, for example:
Capturing statistics value for SQL objects which have been recently modified
MMNL - This process performs frequent and lightweight manageability-related tasks, such as
session history capture and metrics computation.
MMAN - is used for internal database tasks that manage the automatic shared memory. MMAN
serves as the SGA Memory Broker and coordinates the sizing of the memory components.
RBAL - This process coordinates rebalance activity for disk groups in an Automatic Storage
Management instance.
ORBn - performs the actual rebalance data extent movements in an Automatic Storage
Management instance. There can be many of these at a time, called ORB0, ORB1, and so forth.
OSMB - is present in a database instance using an Automatic Storage Management disk group. It
communicates with the Automatic Storage Management instance.
FMON - The database communicates with the mapping libraries provided by storage vendors
through an external non-Oracle Database process that is spawned by a background process called
FMON. FMON is responsible for managing the mapping information. When you specify the
FILE_MAPPING initialization parameter for mapping data files to physical devices on a storage
subsystem, then the FMON process is spawned.
LMON - The Global Enqueue Service Monitor (LMON) monitors the entire cluster to manage the
global enqueues and the resources. LMON manages instance and process failures and the
associated recovery for the Global Cache Service (GCS) and Global Enqueue Service (GES). In
particular, LMON handles the part of recovery associated with global resources. LMON-provided
services are also known as cluster group services (CGS)
LMDx - The Global Enqueue Service Daemon (LMD) is the lock agent process that manages enqueue
manager service requests for Global Cache Service enqueues to control access to global enqueues
and resources. The LMD process also handles deadlock detection and remote enqueue requests.
Remote resource requests are the requests originating from another instance.
LMSx - The Global Cache Service Processes (LMSx) are the processes that handle remote Global
Cache Service (GCS) messages. Real Application Clusters software provides for up to 10 Global
Cache Service Processes. The number of LMSx varies depending on the amount of messaging traffic
among nodes in the cluster.
The LMSx handles the acquisition interrupt and blocking interrupt requests from the remote
instances for Global Cache Service resources. For cross-instance consistent read requests, the LMSx
will create a consistent read version of the block and send it to the requesting instance. The LMSx
also controls the flow of messages to remote instances.
The LMSn processes handle the blocking interrupts from the remote instance for the Global Cache
Service resources by:
Managing the resource requests and cross-instance call operations for the shared resources.
Building a list of invalid lock elements and validating the lock elements during recovery.
Handling the global lock deadlock detection and Monitoring for the lock conversion
timeouts
LCKx - This process manages the global enqueue requests and the cross-instance broadcast.
Workload is automatically shared and balanced when there are multiple Global Cache Service
Processes (LMSx).
DIAG: Diagnosability Daemon – Monitors the health of the instance and captures the data for
instance process failures.
The following shows typical background processes of the RAC instance named NYDB1.
There are at least two new background processes added for an ASM instance:
- ORB0, ORB1… - These perform the actual rebalance data extent movements.
There can be many of these at a time
Any database instance that is using an ASM disk group will contain a background process called
OSMB. The OSMB process is responsible for communicating with the ASM instance. A second
additional background process, called RBAL (just like in the ASM Instance) performs a global open
on ASM disks. A global open means that more than one database instance can be accessing the ASM
disks at a time.