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