oracle background processes

You can see the Oracle background processes with this query:

select *

from

v$session

where

type ='BACKGROUND';

Here are some of the most important Oracle background processes:

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.

CJQ - Job Queue Process (CJQ) - Used for the job scheduler. The job scheduler includes a main program (the coordinator) and slave programs that the coordinator executes. The parameter job_queue_processes controls how many parallel job scheduler jobs can be executed at one time.

CKPT - Checkpoint process writes checkpoint information to control files and data file headers.

CQJ0 - Job queue controller process wakes up periodically and checks the job log. If a job is due, it spawns Jnnnn processes to handle jobs.

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.

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.

LGWR - Log Writer process is responsible for writing the log buffers out to the redo logs. In RAC, each RAC instance has its own LGWR process that maintains that instance’s thread of redo logs.

LMON - Lock Manager process

MMON - The Oracle 10g background process to collect statistics for the Automatic Workload Repository (AWR).

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.

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.

Pnnn - (Optional) Parallel Query Slaves are started and stopped as needed to participate in parallel query operations.

RBAL - This process coordinates rebalance activity for disk groups in an Automatic Storage Management instance.

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.

WMON - The "wakeup" monitor process

Data Guard/Streams/replication Background processes

DMON - The Data Guard Broker process.

The Data Guard monitor process (DMON) is an Oracle backgroundprocess that runs on every site that is managed by the broker. When you start the Data Guard monitor, a DMON process is created.

When you use Data Guard Manager or the CLI to manage an object, the DMON process is the server-side component that interacts with the local instance and the DMON processes running on other sites to perform the requested function. The DMON process is also responsible for monitoring the health of the broker configuration and for ensuring that every site has a consistent copy of the binary configuration files in which the DMON process stores its configuration data.

SNP - The snapshot process.
execute job queues.

SNP processes periodically wake up and execute any queued jobs that are due to be run. You must have at least one SNP process running to execute your queued jobs in the background.

SNP background processes differ from other Oracle background processes in that the failure of an SNP process does not cause the instance to fail. If an SNP process fails, Oracle restarts it.

MRP - Managed recovery process - For Data Guard, the background process that applies archived redo log to the standby database.

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.

RFS - Remote File Server process - In Data Guard, the remote file server process on the standby database receives archived redo logs from the primary database.

QMN - Queue Monitor Process (QMNn) - Used to manage Oracle Streams Advanced Queuing.

DBRM – Database resource manager is responsible for setting plans to users and all other database resource management activities

Database Resource Manager (DRM), which controls the use of computing resources

The Database Resource Manager (DRM) provides database resource management capability for the Oracle Database. The DRM is administered by the PL/SQL Package DBMS_RESOURCE_MANAGER while the necessary privileges are controlled by the DBMS_RESOURCE_MANAGER_PRIVS package. More easily the DRM can be managed via Oracle Enterprise Manager. Note that whatever is the configuration you give, Resource Manager comes into play only if your server CPU is busy at 100% and there are processes waiting for it.

 Oracle 8i introduced Database Resource Manager (DRM), which offers the ability to limit CPU resource usage to groups of application sessions via resource plan directives. Subsequent database releases improved significantly the range and granularity of DRM limitations, including the capability to limit even I/O throughput to specific resource consumer groups. Perhaps the greatest limitation to wider acceptance of DRM, however, was its inability to restrict any one database instance from capturing a majority of the CPU resources to the detriment of all other instances running on the same server.
Since it’s not uncommon today to encounter a database server whose 16, 32, or even 64 CPUs might be shared across dozens of database instances, this was a serious flaw. Oracle 11gR2 overcomes this limitation with an easy-to-implement feature called instance caging. By simply setting the CPU_COUNT initialization parameter to an appropriate value for one or more database instances, DRM can limit CPU resources across multiple databases on the same server to insure that no single instance consumes all CPU resources.

Oracle Real Application Clusters (RAC) Background Processes

The following are the additional processes spawned for supporting the multi-instance coordination:

DIAG: Diagnosability Daemon – Monitors the health of the instance and captures the data for instance process failures.

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).

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

ALSO,

1 dbrm DB resource manager
2 dia0 Diagnosability process
3 fbda Flashback data archiver process
4 vktm Virtual Timekeeper
5 w000 Space Management Co-ordination process
6 smc0 Space Manager process

NOTE : The above six are mandatory processes.

But 11g has 56 new processes added which can be queried using

select name,description from V$bgprocess;