Backgroup Process - 01

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:

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.

RAC Background Processes

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.

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

 

Background Processes 19c

In 19c, the background processes are grouped into three categories: mandatory, optional and slave background processes.

Mandatory Background Processes:  it can be found in all typical database configurations. These processes run by default in a database that is open in read write mode. In a read only database, some of these processes are disabled. If one of these processes fail or is terminated, most likely your database instance will be terminated as well. All of the mandatory background processes are required for the proper functioning of the database.

Optional Background Processes: This are any other background processes that are not defined as mandatory. Usually these processes are specific to a feature or a task that is enabled in the database. If the feature is not enabled, then the background processes is not running.

Slave Background Processes are processes that perform work on behalf of other processes.

Let’s review below each group and their processes.

Mandatory Background Processes:

Process Monitor Process Group – PMON Group

The PMON process as we know it, evolved into a PMON Process Group, which now contains the following processes:

Process Monitor or PMON

Cleanup Main Process or CLMN

Cleanup Helper Processes or CLnn

The role of these processes is to monitor and perfom cleanup of other processes. What do these processes cleanup? These processes cleanup the memory, more precisely the buffer cache, they cleanup resources used by client processes, they reset the status of the active transaction table, they release locks that are no longer required.

PMON monitors and detects the termination of other background processes.

If a server process terminates abnormally, that is if you kill the process at the OS level, or if you issue an ALTER SYSTEM KILL SESSION command, PMON group is the one that does process recovery. PMON process is the one that monitors and detects the abnormal termination. PMON delegates the cleanup to the Cleanup Main Process – CLMN. The CLMN process is the one that performs the cleanup and delegates work to the Cleanup Helper Processes to assist with the cleanup. The number of helper processes is proportional with the amount of work/cleanup that needs to happen. On a unix system you will not see the CLnn processes running all the time. These will be visible, only if cleanup work is needed.

If you check, V$CLEANUP_PROCESS view has one line for each cleanup process in the database:

SQL> select name, state from V$CLEANUP_PROCESS;

Process Manager or PMAN

This background process was introduced with 12cR2, and it’s purpose is to monitor other background processes: shared servers, pooled servers, job queue processes, restartable background processes. PMAN can monitor, spawn and stop the above mentioned processes

Listener Registration Process or LREG

LREG is the process that communicates with the Listener, and registers information about the database with the listener. Prior to 12c this job was performed by PMON. At instance startup , LREG contacts the listener to see if it’s running. If yes, then the information about the database is passed to the listener. If the listener is not running, then LREG periodically checks and tries contacting the listener.

The function and purpose of the other mandatory background processes has not changed from previous releases. I wrote about these before, you can check it out here.

These background processes are:

System Monitor Process or SMON

Database Writer Process or DBW

Log Writer Process or LGWR

Checkpoint Process or CKPT

Manageability Monitor Processes or MMON and MMNL

Recoverer Process or RECO

Optional Background Processes :

The optional background processes are usually specific for a task or feature. Examples of these processes are:

Archiver Processes or ARCn. This process is optional, because the process only exists if the database is in NOARCHIVELOG MODE.

Job Queue Processes CJQ0 and Jnnn. These are also optional, as these processes run user defined jobs.

Flashback Data Archive Process or FBDA. This process archives historical rows of tracked tables into Flashback Data Archives. This process is running only when you are actually using this specific feature.

Space Management Coordinator Process or SMCO. This process coordinates the execution of space related tasks.

Slave Processes

I/O Slave Processes or Innn simulate asynchronous I/O for systems and devices that do not support it.

Parallel Execution (PX) Server Processes. You will see these processes during a parallel execution of a SQL statement.

ABMR :Auto BMR Background

Coordinates execution of tasks such as filtering duplicate block media recovery requests and flood control

ACFS ASM Cluster File System CSS

Delivers CSS membership changes to the Oracle cluster file system. These membership changes are required for the file system to maintain file system consistency within the cluster.

ACMS Atomic Control file to Memory Service

Coordinates consistent control file resource updates to a with its SGA counterpart on all instances in a RAC cluster. Works with a coordinating caller to ensure that an operation is executed on every cluster instance despite possible failures. ACMS is the process in which a distributed operation is called. As a result, this process can exhibit a variety of behaviors. In general, ACMS is limited to small, non-blocking state changes for a limited set of cross-instance operations.

APnn Logical Standby / Streams Apply Process Coordinator

Obtains transactions from the Streams reader server and passes them to the Streams apply servers

AQPC Advanced Queuing Process Coordinator

AQPC is responsible for performing administrative tasks for AQ Master Class Processes including commands like starting, stopping, and other administrative tasks. This process is automatically started on instance startup.

ARBn  ASM Rebalance Process

Rebalances data extents within an ASM disk group.

ARCn Archiver

Creates archive copies of redo log files when they are full or an online redo log switch occurs.

ARCn processes exist only when the database is in ARCHIVELOG mode and automatic archiving is enabled. LGWR cannot reuse/overwrite an online redo log group until it has been archived.

The database can start multiple archiver processes as needed to ensure that the archiving of filled online redo logs does not fall behind. Possible processes include ARC0-ARC9 and ARCa-ARCt. The LOG_ARCHIVE_MAX_PROCESSES initialization parameter specifies the number of ARC n processes that the database initially invokes: Not the maximum number of possible processes. ARSn ASM Recovery Slave Process The ASM RBAL background process coordinates and spawns one or more of these slave processes to recover aborted ASM transactional operations. These processes run only in the Oracle ASM instance.

ASMB ASM Background

Communicates with the ASM instance, managing storage and providing statistics. ASMB runs in ASM instances when the ASMCMD cp command runs or when the database instance first starts if the server parameter file is stored in ASM. ASMB also runs with Oracle Cluster Registry on ASM. ASMB stays open as long as ASM is open and available.

ASnn Logical Standby / Streams Apply Process Reader Server or Apply Server

With Streams, when the reader server finishes computing dependencies between LCRs and assembling transactions, it returns the assembled transactions to the coordinator process: Query V$STREAMS_APPLY_READER for information about the reader server background process.

An apply server receives the transactions from the coordinator background process, and either applies database changes in LCRs or sends LCRs or messages to apply handlers. Apply servers can also enqueue a queue. If an apply server encounters an error, then it then tries to resolve the error with a user-specified conflict handler or error handler. If an apply server cannot resolve an error, then it rolls back the transaction and places the entire transaction, including all of its messages, in the error queue. When an apply server commits a completed transaction, this transaction has been applied. When an apply server places a transaction in the error queue and commits, this transaction also has been applied. Query V$STREAMS_APPLY_SERVER for information about the apply server background process. The coordinator process name is ASnn, where nn can include both letters and numbers.

Bnnn ASM Blocking Slave for GMON

Performs actions that require waiting for resources on behalf of GMON. A Bnnn slave is spawned when an ASM disk is taken offline. The Off-line timer processing and disk drop are performed in this slave. Up to five process (B000 to B004) can exist depending on the load.

BMRn Automatic Block Media Recovery Slave Pool

When a process submits a block media recovery request to ABMR, it dynamically spawns slave processes (BMRn) to perform the recovery. BMRn processes fetch blocks from a real-time readable standby database. ABMR and BMRn terminate if idle for a long time.

BWnn Database Writer Process

Writes modified blocks from the database buffer cache to the data files.

CJQ0 Job Queue Coordinator

Selects jobs that need to be run from the data dictionary and spawns job queue slave processes (Jnnn) to run the jobs. This process is automatically started and stopped as needed by the Scheduler. The JOB_QUEUE_PROCESSES initialization parameter specifies the maximum number of processes that can be created for job executions. CJQ0 starts only as many job queue processes as required by the number of jobs to run and available resources.

CKPT Checkpointer

At specific times CKPT starts a checkpoint request by messaging DBWn to begin writing dirty buffers. On completion of individual checkpoint requests, CKPT updates data file headers and control files to record the most recent checkpoint.

CLnn Cleanup Slave Process

Cleanup slaves assist in the cleanup of dead processes and killed sessions. The number of slaves will be proportional to the amount of cleanup work to be done and the current efficiency of cleanup.

CLG (new 18c)

Persistent Cluster Flash Cache Background Process

For Oracle Data Appliance only, in the event of an instance crash, the surviving instance will recover the dead instance's database flash cache. The CLG process will perform actions related to scanning the dead instance's database flash cache and claim flash blocks mastered by the dead instance

CLMN

Cleanup Main Process

Periodically performs cleanup of all the following: dead processes, killed sessions, transactions, network connections, idle sessions, detached transactions, and detached network connections that have exceeded their idle timeout.

CPnn

Streams Capture

Captures database changes from the redo log with LogMiner utilizing one reader server that reads the redo log and divides it into regions, one or more preparer servers that scan the redo log, and one builder server that merges redo records from the preparer servers. Each reader server, preparer server, and builder server is a separate process. Query the V$STREAMS_CAPTURE view for information about this background process.

The capture process name is CPnn, where nn can include letters and numbers. The underlying LogMiner process name is MSnn, where nn can include letters and numbers.

DBMS_LOGMNR

CRnn

LMS CR Slave Process

Offloads the work from LMS so that blocks that require lots of UNDO to be applied do not block the LMS. Such requests are passed on to the slave so that the LMS is not stalled.

CSnn

Streams Propagation Sender

Sends LCRs to a propagation receiver. In an Oracle Streams combined capture and apply optimization, the propagation sender sends LCRs directly to the propagation receiver to improve performance. The propagation receiver passes the LCRs to an apply process. Query V$PROPAGATION_SENDER for information about a propagation sender.

Streams

CTWR

Block Change Tracking Writer

CTWR tracks changed blocks as redo is generated at a primary database and as redo is applied at a standby database. The process is slightly different depending on the type of database. Buffer size can be configured with a number of undocumented parameter listed here in the Undocumented Parameters section.

Block Change Tracking

CXnn

Streams Propagation Sender Process

Sends LCRs to an propagation receiver. The propagation sender process name is CXnn, where nn can include letters and numbers. In an Oracle Streams combined capture and apply optimization, the propagation sender sends LCRs directly to the propagation receiver to improve performance. The propagation receiver passes the LCRs to an apply process. Query V$PROPAGATION_SENDER for information about a propagation sender.

DBMS_RESOURCE_MANAGER

Dnnn

Dispatcher

Performs network communication in the shared server architecture. In the shared server architecture, clients connect to a dispatcher process, which creates a virtual circuit for each connection. When the client sends data to the server, the dispatcher receives the data into the virtual circuit and places the active circuit on the common queue to be picked up by an idle shared server. The shared server then reads the data from the virtual circuit and performs the database work necessary to complete the request. When the shared server must send data to the client, the server writes the data back into the virtual circuit and the dispatcher sends the data to the client. After the shared server completes the client request, the server releases the virtual circuit back to the dispatcher and is free to handle other clients.

Several initialization parameters relate to shared servers. The principal parameters are: DISPATCHERS, SHARED_SERVERS, MAX_SHARED_SERVERS, LOCAL_LISTENER, REMOTE_LISTENER.

DBRM

Database Resource Manager

Only active if a resource plan is enabled: Sets resource plans and performs other tasks related to the Database Resource Manager.

DBMS_RESOURCE_MANAGER

DBWn

Database Writers

Writes modified blocks from the database buffer cache to the data files on disk.DBWn also writes checkpoints, manages file open synchronization, and the logging of Block Written records.

DBWn performs multiblockwrites when possible to improve efficiency but because it's writes are scattered throughout the disk they are usually slower than the sequential writes performed by LGWR. The number of blocks written in a multiblock write varies by operating system'.

The DB_WRITER_PROCESSES initialization parameter specifies the number of DBWn processes (DBW0-DBW9 and DBWa-DBWz). The database selects an appropriate default setting for this parameter or adjusts a user-specified setting based on the number of CPUs and processor groups.

Learn How To Obliterate Processor Caches: Configure Lots and Lots of DBWR Processes. Part 1.

DIA0

Hang detection diagnostic process

Detects and aids in resolving hangs and deadlocks

DIAG

Diagnostic Capture

Performs diagnostic dumps requested by other processes and dumps triggered by process or instance termination. In Oracle RAC, DIAG performs global diagnostic dumps requested by remote instances.

Automatic Diagnostic Repository (ADR)

DMnn

DataPump

Coordinates the Data Pump job tasks performed by Data Pump worker processes and handles client interactions. The Data Pump master (control) process is started during job creation and coordinates all tasks performed by the Data Pump job. It handles all client interactions and communication, establishes all job contexts, and coordinates all worker process activities on behalf of the job.

DataPump

DMON

Data Guard Broker Monitor

Manages and monitors a database that is part of a Data Guard broker configuration. When you start the Data Guard broker, a DMON process is created. DMON runs for every database instance that is managed by the broker. DMON interacts with the local database and the DMON processes of the other databases to perform the requested function. DMON also monitors the health of the broker configuration and ensures that every database has a consistent description of the configuration.

DMON maintains profiles about all database objects in the broker configuration in a binary configuration file. A copy of this file is maintained by the DMON process for each of the databases that belong to the broker configuration. The process is created when the DG_BROKER_START initialization parameter is set to true.

Data Guard

DRnn

ASM Disk Resynchronization Slave

Resynchronizes the contents of an offline disk. When a disk online SQL command is issued on a disk or disks that are offline, ASM spawns DRnn. Depending on the load, more than one slave may be spawned.

DSKM

Dismon Slave

Conduit between the database, ASM instances, and the Master Diskmon daemon to communicate information to Exadata storage. This process is active only if Exadata Storage is used. DSKM performs operations related to Exadata I/O fencing and Exadata cell failure handling.

DWnn

DataPump Worker

Performs Data Pump tasks as assigned by the Data Pump master process. The Data Pump worker process is responsible for performing tasks that are assigned by the Data Pump master process, such as the loading and unloading of metadata and data.

DataPump

Ennn

Emon Slave

The database event management and notification load is distributed among the EMON slave processes. These processes work on the system notifications in parallel, offering a capability to process a larger volume of notifications, a faster response time, and a lower shared memory use for staging notifications.

Real Application Clusters

EMNC

Emon Coordinator

Coordinates event management and notification activity in the database, including Streams Event Notifications, Continuous Query Notifications, and Fast Application Notifications.

Real Application Clusters

FBDA

Flashback Data Archiver

This technology is part utilized by Flashback Archive marketed by Oracle as "Total Recall." When a transaction that modifies a tracked table commits, FBDA stores the pre-image of the rows in the archive. FDBA maintains metadata on the current rows and tracks how much data has been archived. FBDA is also responsible for automatically managing the flashback data archive for space, organization (partitioning tablespaces), and retention. FBDA also keeps track of how far the archiving of tracked transactions has progressed.

Flashback Archive

FDnn

Oracle ASM Stale FD Cleanup Slave Process

Cleans up Oracle ASM stale file descriptors on foreground processes.

FENC

Fence Monitor Process

Processes fence requests for RDBMS instances which are using Oracle ASM instances.

FMON

File Mapping Monitor

The DBMS_STORAGE_MAP package enables control of the mapping operations. When instructed by the user, FMON builds mapping information and stores it in the SGA, refreshes the information when a change occurs, saves the information to the data dictionary, and restores it to the SGA at instance startup.

FMON is started by the database whenever the FILE_MAPPING initialization parameter is set to true.

DBMS_STORAGE_MAP

FSFP

Data Guard Broker Fast Start Failover Pinger

This process is created when Fast Start Failover is enabled.

Data Guard

GCRn

Global Conflict Resolution Slave Process

Transient slaves started and stopped as required by LMHB to perform synchronous or resource intensive tasks

GEN0

General Task Execution Monitor

Performs required tasks including SQL and DML

TBD

GMON

ASM Disk Group Monitor

Monitors all disk groups mounted in an ASM instance and is responsible for maintaining consistent disk membership and status information. Membership changes result from adding and dropping disks, whereas disk status changes result from taking disks offline or bringing them online. Calls Bnnn slaves to perform the work.

GTXn

Global Transaction

Supports global XA transactions with RAC

These processes help maintain the global information about XA global transactions throughout the cluster. They support global transaction two phase commit anywhere in the cluster so that an Oracle RAC database behaves as a single system to externally coordinated distributed transactions.

The GLOBAL_TXN_PROCESSES initialization parameter specifies the number of GTXn processes, where n is 0-9 or a-j. The database automatically tunes the number of these processes based on the workload of XA global transactions. You can disable these processes by setting the parameter to 0. If you try to run XA global transactions with these process disabled, an error is returned.

Real Application Clusters

Innn

Disk and Tape I/O Slave Process

Serves as an I/O slave process spawned on behalf of DBWR, LGWR, or an RMAN backup session.

IMCO

In-Memory Coordinator

Initiates background population and repopulation of in-memory enabled objects.

In-Memory Database

IMR0

Instance Membership Recovery Slave Process

Performs synchronous tasks on behalf of LMON.

INSV

Data Guard Broker Instance Slave Process

Performs Data Guard broker communication among instances in an Oracle RAC environment

Data Guard

IPC0

IPC Service Background Process

Common background server for basic messaging and RDMA primitives based on IPC (Inter-process communication) methods.

Jnnn

Joe Queue Slave Process

Executes jobs assigned by the job coordinator.

JPn

Java Patching Slave Process

Patches and updates the Java in the database classes.

Lnnn

Pooled Server

Manages client requests in database resident connection pooling

In Database Resident Connection Pooling, clients connect to a connection broker process. When a connection becomes active, the connection broker hands off the connection to a compatible pooled server process. The pooled server process performs network communication directly on the client connection and processes requests until the client releases the server. After being released, the connection is returned to the broker for monitoring, leaving the server free to handle other clients.

DBMS_CONNECTION_POOL

LCKn

Lock Process

Manages global enqueue requests and cross-instance broadcasts. Possible processes are LCK0 and LCK1.

LDDn

Global Enqueue Service Daemon Helper Slave

Helps the LMDn processes with various tasks. There can be up to 36 of these slave processes (LDD0-LDDz).

LGnn

Log Writer Worker

On multiprocessor systems, LGWR creates worker processes to improve the performance of writing to the redo log. LGWR workers are not used when there is a SYNC standby destination. Possible processes include LG00-LG99.

LGWR

Log Writer Process

Redo log entries are generated in the redo log buffer of the system global area (SGA). LGWR writes the redo log entries sequentially into a redo log file. If the database has a multiplexed redo log, then LGWR writes the redo log entries to the current member of each redo log group.

LMDn

Global Enqueue Service Daemon Process

Manages incoming remote resource requests from other instances.

LMFC

Lock Manager Flash Cache Process

For Oracle Database Appliance only, performs actions related to recovery of a dead instance’s database flash cache.

ODA

LMHB

Global Cache/ Enqueue Service Heartbeat Monitor

Monitor the heartbeat of several processes including CKPT, DIAn, LCKn, LGnn, LGWR, LMDn, LMON, LMSn , and RMSn to ensure they are running normally without blocking or spinning.

LMON

Global Enqueue Service Monitor Process

Monitors an Oracle RAC cluster to manage global resources by maintaining an instance membership within Oracle RAC. The process detects instance transitions and performs reconfiguration of GES and GCS resources.

LMSn

Global Cache Service

Resource control with RAC instances

LMS, where n is 0-9 or a-z, maintains a lock database for Global Cache Service (GCS) and buffer cache resources. This process receives, processes, and sends GCS requests, block transfers, and other GCS-related messages.

Real Application Clusters

LREG

Listener Registration Process

Registers the instance with the listeners. by notifying the listeners about instances, services, handlers, and endpoints.

LSP0

Logical Standby Coordinator

LSP0 is the initial process created upon startup of Data Guard SQL Apply. In addition to managing LogMiner and Apply processes, LSP0 is responsible for maintaining inter-transaction dependencies and appropriately scheduling transactions with applier processes. LSP0 is also responsible for detecting and enabling runtime parameter changes for the SQL Apply product as a whole.

Data Guard

LSP1

Logical Standby Dictionary Build

The LSP1 process is spawned on a logical standby database that is intended to become the new primary database. A logical standby database becomes a primary database by means of switchover or failover. The dictionary is necessary for logical standby databases to interpret the redo of the new primary database.

Data Guard

LSP2

Logical Standby Set Guard

Determines which objects will be protected

The LSP2 process is created as needed during startup of SQL Apply to update the list of objects that are protected by the database guard.

Data Guard

Mnnn

MMON Slave

Performs manageability tasks dispatched to them by MMON

DBMS_ADDM

MARK

Mark AU for Resynchronization Coordinator. Marks ASM allocation units as stale

MARK essentially tracks which extents require resynchronization for offline disks. This process runs in the database instance and is started when the database instance first begins using the ASM instance. If required, MARK can also be started on demand when disks go offline in the ASM redundancy disk group.

MMAN

Memory Manager

Performs instance memory component resizing

MMNL

Manageability Monitor Light

Performs multiple manageability related tasks including session history capture and metrics computation

MMON

Manageability Monitor

Performs multiple manageability tasks including taking AWR snapshots and ADDM analysis

DBMS_ADDM

MRP0

Physical Data Guard Managed Standby Recovery

Spawned at the start of redo apply on a Data Guard physical standby. MRP0 handles the extraction and coordinates the application of redo on the physical standby

Data Guard

MSnn

Log Miner Worker

Multiple MSnn processes can exists, where n is 0-9 or a-Z. A minimum of three MSnn processes work as a group to provide transactions to a LogMiner client, for example, a logical standby database. There may be more than one such group, for example, Downstream Capture sessions.

DBMS_LOGMNR

Nnnn

Connection Broker

In Database Resident Connection Pooling, clients connect to a connection broker process. When a connection becomes active, the connection broker hands off the connection to a compatible pooled server process. The pooled server process performs network communication directly on the client connection and processes requests until the client releases the server. After being released, the connection is returned to the broker for monitoring, leaving the server free to handle other clients.

DBMS_CONNECTION_POOL

NFSn

Direct NFS Dispatcher IO Slave Process

Performs direct NFS I/O for database processes.

NSSn

Redo Transport NSS1

SYNC transport LGWR Slave

Acts as a slave for LGWR when SYNC transport is configured for a remote standby destination

Data Guard

NSVn

Data Guard Broker NetSlave

Broker network communications

Created when a Data Guard broker configuration is enabled. There can be as many NSVn processes (where n is 0- 9 and A-U) created as there are databases in the Data Guard broker configuration.

Data Guard

Onnn

ASM Connection Pool

Slave processes spawned on demand to communicate with an ASM instance

OCFn

ASM CF Connection Pool

Maintains a connection to the ASM instance for metadata related operations.

OFnn

Oracle File Server Background Process Thread

Serves file system requests submitted to an Oracle instance.

OFSD

Oracle File Server Background Process

Serves file system requests submitted to an Oracle instance.

Listens for new file system requests, both management (like mount, unmount, and export) and I/O requests, and executes them using Oracle threads.

Pnnn

Parallel Query Slave

Parallel Query has two components: a foreground process that acts as query coordinator and a set of parallel slaves (Pnnn) that are background processes. These background processes are spawned or reused during the start of a parallel statement. They receive and carry out units of work sent from the query coordinator.

The maximum number of processes is controlled by the PARALLEL_MAX_SERVERS initialization parameter. Slave processes are numbered from 0 to the value of the initialization parameter PARALLEL_MAX_SERVERS. If the query is a GV$ query, then these background processes are numbered backward, beginning with PZ99, then PZ98, etc.

PING

Interconnect Latency Measurement

Every few seconds, the process in one instance sends messages to each cluster instance. The message is received by PING on the target instance and the round trip time measured and collected

Real Application Clusters

PMAN

Process Manager

Manages several background processes including shared servers, pooled servers, and job queue processes.

PMAN monitors, spawns, and stops the following as needed:

• dispatcher and shared server processes

• connection broker and pooled server processes for database resident connection pools

• job queue processes

• restartable background processes

PMON

Process Monitor

PMON periodically performs cleanup of all the following:

Processes that died abnormally

Sessions that were killed

Detached transactions that have exceeded their idle timeout

Detached network connections which have exceeded their idle timeout

In addition, PMON monitors, spawns, and stops the following as needed:

Dispatcher and shared server processes

Job queue processes

Pooled server processes for database resident connection pooling

Restartable background processes

PMON is also responsible for registering information about the instance and dispatcher processes with the network listener.

PRnn

Parallel Recovery

A slave for the coordinator process performing parallel media recovery carrying out tasks assigned by the coordinator. The default number of these processes is based on number of CPUs. Parallel recovery sessions can be found in the  gv$px_session dynamic performance view.

Tuning

PSP0

Processor Spawner

After startup spawns background processes

PXMN

Parallel Execution Monitor

Spawns parallel server processes on local instances in an Oracle RAC environment for Query Coordinator in remote instances.

Qnnn

AQ Coordinator (QMNC) Slave

Slave processes initiated by QMNC

DBMS_AQADM

QMNC

AQ Coordinator

Responsible for facilitating various background activities required by AQ and Streams such as management of messages, non-persistent queues, and resource cleanup. Also dynamically spawns Qnnn slave processes as required.

Note that if the AQ_TM_PROCESSES initialization parameter is set to 0, this process will not start. The database writes the following message to the alert log: "WARNING: AQ_TM_PROCESSES is set to 0. System might be adversely affected."

DBMS_AQADM

QMnn

AQ Master Class Process

Monitors AQ QMNC is the non-sharded queue master process responsible for facilitating various background activities required by AQ and Oracle Streams: time management of messages, management of nonpersistent queues, cleanup of resources, and so on. QMNC dynamically spawns Qnnn processes as needed for performing these tasks. Note that if the AQ_TM_PROCESSES initialization parameter is set to 0, this process will not start. The database writes the following message to the alert log: WARNING: AQ_TM_PROCESSES is set to 0. System might be diversely affected.

Advanced Queueing

Rnnn

ASM Block Remap Slave

A database instance reading from an Oracle ASM disk group can encounter an error during a read. If possible, Oracle ASM asynchronously schedules a Rnnn slave process to remap this bad block from a mirror copy.

RBAL

ASM Rebalance Master

In an ASM instance, coordinates disk group rebalance

RCBG

Result Cache BackGround

Processes global result cache invalidations and other messaging generated by server processes attached to other instances in a RAC cluster.

DBMS_RESULT_CACHE

RECO

Recoverer

Uses the information in the pending transaction table to finalize the status of in-doubt transactions. At timed intervals, the local RECO process attempts to connect to remote databases and commit or rollback of the local portion of any pending distributed transactions. All transactions resolved by RECO are removed from the pending transaction table.

RLnn

Reset Logs Process

Clear online redo logs when performing open resetlogs and converting to physical standby. Possible processes are RL00 through RL31.

Open Reset Logs

RM

Rat Masking Slave Process

Extracts and masks bind values from workloads like SQL tuning sets and DB Replay capture files.

Real Application Testing

RMON

Rolling Migration Monitor Process

Manages the rolling migration procedure for an Oracle ASM cluster

DBMS_ROLLING

RMSn

RAC Management

Performs a variety of tasks, including creating resources related to Oracle RAC when new instances are added to a cluster

Real Application Clusters

RMVn

Global Cache Service Remaster Process

Performs remastering for cluster reconfiguration and dynamic remastering.

Real Application Clusters Remastering

RPOP

Instant Recovery Repopulation Daemon

The RPOP process is responsible for re-creating and repopulating data files from snapshots files. It works with the instant recovery feature to ensure immediate data file access. The local instance has immediate access to the remote snapshot file's data, while repopulation of the recovered primary data files happens concurrently. Any changes in the data are managed between the instance's DBW processes and RPOP to ensure the latest copy of the data is returned to the user.

RPnn

Workload Capture

These are worker processes spawned by calling DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE. RPnn processes execute in parallel and each handles a set of assigned files.

The number of worker processes is controlled by the DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE parallel_level parameter which, by default, is NULL. Then, the number of worker processes is equal to the value in v$parameter for 'cpu_count.' When parallel_level is set to 1 no worker processes are spawned.

RSM0

Data Guard Broker Worker Monitoring for DMON

Performs monitoring and management tasks related to Data Guard on behalf of DMON. The process is created when the Data Guard broker configuration is enabled.

RSMN

Remote Slave Monitoring (RAC)

Manages the creation of slave processes that perform tasks on behalf of a coordinating process running in another cluster instance providing communication with their coordinators and peers

RVWR

Recovery Writer

Creates flashback logs and writes Flashback Database data from the flashback buffer in the SGA to the flashback logs. Also performs some tasks for flashback log automatic management

Snnn

Shared Server (formerly MTS)

In the shared server architecture, clients connect to a dispatcher process, which creates a virtual circuit for each connection. When the client sends data to the server, the dispatcher receives the data into the virtual circuit and places the active circuit on the common queue to be picked up by an idle shared server. The shared server then reads the data from the virtual circuit and performs the database work necessary to complete the request. When the shared server must send data to the client, the server writes the data back into the virtual circuit and the dispatcher sends the data to the client. After the shared server completes the client request, the server releases the virtual circuit back to the dispatcher and is free to handle other clients.

Several initialization parameters relate to shared servers. The principal parameters are: DISPATCHERS, SHARED_SERVERS, MAX_SHARED_SERVERS, LOCAL_LISTENER, REMOTE_LISTENER.

SAnn

SGA Allocator

A small fraction of SGA is allocated during instance startup. This process allocates the rest of SGA in small chunks. The process exits upon completion of SGA allocation. The possible processes are SA00 - SAzz.

SCCN

ASM Disk Scrubbing Slave Check Process

Acts as a slave process for SCRB and performs the checking operations. The possible processes are SCC0-SCC9.

SCM0

DLM Statistics Collection and Management Slave

Collects and manages statistics related to global enqueue service (GES) and global cache service (GCS)

SCRB

ASM Disk Scrubbing Master Process

Coordinates Oracle ASM disk scrubbing operations.

SCRn

ASM Disk Scrubbing Slave Repair Process

Acts as a slave process for SCRB and performs the repairing operations. The possible processes are SCR0-SCR9

SCVn

Performs Oracle ASM disk scrubbing repair operations

Performs Oracle ASM disk scrubbing verify operation.

SMCO

Space Monitor Coordinator

Coordinates the execution of space management tasks, including proactive space allocation and reclamation. Dynamically spawns Wnnn slave processes to perform the tasks both of which are used for in-memory column store maintenance.

SMON

System Monitor

Performs critical tasks such as instance recovery and dead transaction recovery, and maintenance tasks such as temporary space reclamation, data dictionary cleanup, and undo tablespace management. In more detail:

Creates and manages the temporary tablespace metadata

Reclaims space used by orphaned temp segments

Maintains the undo tablespace by on-lining, off-lining, and shrinking undo segments based on undo space usage statistics

Cleans up the data dictionary when in a transient and inconsistent state

Maintains the SCN to time mapping table used to support Flashback

In an Oracle RAC database, the SMON process of one instance can perform instance recovery for other instances that have failed.

SP (new 18c)

SPA (SQL Performance Analyzer) Slave

Analyzes single SQL statements sent from SQL Performance Analyzer (SPA)

SVCB

Service Background Process

Part of RAC:  Provides database service run-time load balancing and topology information to clients.

Every 30 seconds the process processes and publishes run-time load-balancing information and keeps the topology information current. This process is started only if Oracle Real Application Clusters (Oracle RAC) is enabled.

TEMn

ASM Disk Test Error Emulation

I/O errors can be emulated on ASM disk I/O through named events. The scope can be the process, instance, or cluster. Optionally, a set of AUs can be chosen for error emulation.

TMON

Redo Transport Process Monitor

Part of DataGuard

Not in 18c reference documentation.

TTnn

Redo Transport Slave Process

Ships redo from current online and standby redo logs to remote standby destinations configured for ASYNC transport.

TBD

Unnn

Container Process for Threads

Database container operating system processes where database backgrounds processes like SMON, CJQ0, and database foreground processes run. The V$PROCESS view lists database processes running in these container processes. These container processes are created only when the THREADED_EXECUTION initialization parameter is set to TRUE. The number of these processes vary depending on the active database processes. On a host with multiple NUMA nodes, there will be at least one Unnn process per NUMA node.

These processes are fatal processes, if any of them is killed, it will result in instance termination. These processes exit when the instance is shut down or terminated.

VBGn

Volume Background

ASM and O/S volume driver communications

Handles messages originating from the volume driver in the operating system and sends them to the ASM instance. Can run as multiple processes, where n is 0-9.

VDBG

Volume Driver

Handles requests to lock or unlock an extent for rebalancing, volume resize, disk offline, add or drop a disk, force and dismount disk group to the Dynamic Volume Manager driver

VInn

Volume I/O

Route ADVM volume I/O for ASM instances on compute nodes within an Exadata

These processes handle requests for I/Os targeted at storage not locally accessible. They are used for Exadata targeted storage as well. These background processes only start when an ASM Volume is created and set up to be used. One process will start for each NUMA node on target machines. Under normal operation on non-Exadata hardware and on Exadata hardware that is not utilizing ASM volumes, these processes will not be started. There can be up to 32 VI processes, and they are named sequentially from VI00 to VI31.

VKRM

Virtual Scheduler (Resource Manager)

Manages CPU scheduling for all managed processes in accordance with an active resource plan

VKTM

Virtual Timekeeper

Instance time publisher publishing two time sets. One is a wall clock time using a seconds interval and a higher resolution time (which is not wall clock time) for interval measurements. The VKTM timer service centralizes time tracking and offloads multiple timer calls from other clients.

VMB0

Volume Membership

As an I/O capable client maintains cluster membership on behalf of the ASM volume driver.

VUBG

Volume drive Umbilicus Background

Relays messages between Oracle ASM instance and Oracle ASM Proxy instance that is used by ADVM (for ACFS)

Wnnn

Space Management Slave

Slave processes dynamically spawned by SMCO to perform background space management tasks. These tasks include pre-allocating space for locally managed tablespaces and SecureFiles segments based on space usage growth analysis and reclaiming space from dropped segments. At most 10 Wnnn slaves can run on an instance. The slaves acts as autonomous agents and after task completion, a process automatically picks up another task from the queue or terminates itself after being idle for an extended time period.

XDMG

Exadata Automation Storage Manager

Monitors all configured Exadata cells for state changes, such as a bad disk getting replaced, and performs the required tasks for such events. Its primary tasks are to watch for inaccessible disks and cells and when they become accessible again, and to initiate the ASM ONLINE operation. The ONLINE operation is handled by XDWK.

XDWK

Exadata Automation Manager XDMG Slave

Started when asynchronous actions such as ONLINE, DROP, and ADD an ASM disk are requested by XDMG. After a 5 minute period of inactivity, this process will shut itself down.

Xnnn

ASM Disk Expel Slave

At the completion of ASM Rebalance expels dropped disks