You can see the Oracle background processes with this query:
select program 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.
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.
SNP - The
snapshot process.
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.
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.
QMN - Queue Monitor Process (QMNn) - Used to manage Oracle Streams Advanced Queuing.
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.
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
All Background Processes
The following describes
Oracle Database background processes. In this context, a background process is defined as any process that is
listed in
V$PROCESS
and has a non-null value in the pname
column.
The External
Properties column lists the type of instance in which the process runs. If the
process is specific to a particular feature, then the column names the feature.
Name
|
Expanded Name
|
Short Description
|
Long Description
|
External Properties
|
ABMR
|
Auto BMR Background Process
|
Coordinates execution of tasks
such as filtering duplicate block media recovery requests and performing
flood control
|
When a process submits a block
media recovery request to ABMR, it dynamically spawns slave processes (BMRn) to perform the recovery. ABMR and BMRn terminate
after being idle for a long time.
See Also: Oracle Database Backup and
Recovery User's Guide |
Database instance
|
ACFS
|
ASM Cluster File System CSS
Process
|
Tracks the cluster membership in
CSS and informs the file system driver of membership changes
|
ACFS 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.
|
ASM instance, Oracle RAC
|
ACMS
|
Atomic Control File to Memory
Service Process
|
Coordinates consistent updates to
a control file resource with its SGA counterpart on all instances in an
Oracle RAC environment
|
The ACMS process works with a
coordinating caller to ensure that an operation is executed on every instance
in Oracle RAC despite 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, nonblocking state changes
for a limited set of cross-instance operations.
|
Database instance, Oracle RAC
|
APnn
|
Logical Standby / Streams Apply
Process Coordinator Process
|
Obtains transactions from the
reader server and passes them to apply servers
|
The coordinator process name is
APnn, where nn can include letters and numbers.
See Also: Oracle Streams Concepts and
Administration |
Database instance, Data Guard,
Oracle Streams
|
ARBn
|
ASM Rebalance Process
|
Rebalances data extents within an
ASM disk group
|
Possible processes are ARB0-ARB9
and ARBA.
|
ASM instance
|
ARCn
|
Archiver Process
|
Copies the redo log files to
archival storage when they are full or an online redo log switch occurs
|
ARCn processes exist only when the
database is in
The database starts 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.ARCHIVELOG mode and automatic archiving is
enabled, in which case ARCn automatically archives online redo
log files. LGWR cannot reuse and overwrite an online redo log group until it
has been archived.The LOG_ARCHIVE_MAX_PROCESSES initialization parameter specifies
the number of ARCn processes that the database
initially invokes.See Also: Oracle Database Concepts and Oracle Database Administrator's Guide |
Database instance
|
ASMB
|
ASM Background Process
|
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. |
Database and ASM instances
|
ASnn
|
Logical Standby / Streams Apply
Process Reader Server or Apply Server
|
·
Computes dependencies between logical change
records (LCRs) and assembles messages into transactions (Reader Server)
·
Applies LCRs to database objects or passes
LCRs and user messages to their appropriate apply handlers (Apply Server)
|
When the reader server finishes
computing dependencies between LCRs and assembling transactions, it returns
the assembled transactions to the coordinator process. Query
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_READER for information about the reader
server background process.V$STREAMS_APPLY_SERVER for information about the apply
server background process.The coordinator process name is ASnn, where nn can include letters and numbers. |
Database instance
|
BMRn
|
Automatic Block Media Recovery
Slave Pool Process
|
Fetches blocks from a real-time
readable standby database
|
When a process submits a block
media recovery request to ABMR, it dynamically spawns slave processes (BMRn) to perform the recovery. BMRnprocesses
fetch blocks from a real-time readable standby database. ABMR and BMRn terminate
after being idle for a long time.
See Also: Oracle Database Backup and
Recovery User's Guide |
Database instance
|
Bnnn
|
ASM Blocking Slave Process for
GMON
|
Performs maintenance actions on
ASM disk groups
|
Bnnn performs actions that require
waiting for resources on behalf of GMON. GMON must be highly available and
cannot wait.
A Bnnn slave
is spawned when a disk is taken offline in an ASM disk group. Offline timer
processing and drop of the disk are performed in this slave. Up to five
process (B000 to B004) can exist depending on the load. |
ASM instance
|
CJQ0
|
Job Queue Coordinator Process
|
Selects jobs that need to be run
from the data dictionary and spawns job queue slave processes (Jnnn) to run the jobs
|
CJQ0 is automatically started and
stopped as needed by Oracle Scheduler.
The JOB_QUEUE_PROCESSES initialization parameter specifies
the maximum number of processes that can be created for the execution of
jobs. CJQ0 starts only as many job queue processes as required by the number
of jobs to run and available resources.See Also: Oracle Database Concepts and Oracle Database Administrator's Guide |
Database instance
|
CKPT
|
Checkpoint Process
|
Signals DBWn at checkpoints and updates all the
data files and control files of the database to indicate the most recent checkpoint
|
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 most recent checkpoint.
See Also: Oracle Database Concepts |
Database and ASM instances
|
CPnn
|
Streams Capture Process
|
Captures database changes from
the redo log by using the infrastructure of LogMiner
|
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. The capture process includes 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 process. Query the
See Also: Oracle Streams Concepts and
AdministrationV$STREAMS_CAPTURE view for information about this
background process. |
Database instance, Oracle Streams
|
CSnn
|
Streams Propagation Sender
Process
|
Sends LCRs to a propagation
receiver
|
The propagation sender process
name is CSnn, 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. |
Database instance, Oracle Streams
|
CSnn
|
I/O Calibration Process
|
Issues I/Os to storage as part of
storage calibration.
|
CSnn slave processes are started on
execution of the
DBMS_RESOURCE_MANAGER.CALIBRATE_IO() procedure. There is one slave
process per CPU on each node of the database. |
Database instance, Oracle RAC
|
CTWR
|
Change Tracking Writer Process
|
Tracks changed data blocks as
part of the Recovery Manager block change tracking feature
|
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.
See Also: Oracle Database Backup and
Recovery User's Guide |
Database instance
|
DBRM
|
Database Resource Manager Process
|
Sets resource plans and performs
other tasks related to the Database Resource Manager
|
If a resource plan is not
enabled, then this process is idle.
See Also: Oracle Database Administrator's
Guide |
Database instance
|
DBWn
|
Database Writer Process
|
Writes modified blocks from the
database buffer cache to the data files
|
The primary responsibility of DBWn is
to write data blocks to disk. DBWn also handles checkpoints, file open
synchronization, and logging of Block Written records.
In many cases the blocks that DBWn writes are scattered throughout the
disk. Thus, the writes tend to be slower than the sequential writes performed
by LGWR. DBWn performs multiblock writes when
possible to improve efficiency. 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.See Also: Oracle Database Concepts and Oracle Database Performance Tuning Guide |
Database instance
|
DIA0
|
Diagnostic Process
|
Detects and resolves hangs and deadlocks |
ASM and Database instances
|
|
DIAG
|
Diagnostic Capture Process
|
Performs diagnostic dumps |
DIAG 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. |
ASM and Database instances
|
DMnn
|
Data Pump Master Process
|
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.
|
Database instance, Data Pump
|
DMON
|
Data Guard Broker Monitor Process
|
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 .See Also: Oracle Data Guard Broker |
Database instance, Data Guard
|
Dnnn
|
Dispatcher Process
|
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 .See Also: Oracle Database Concepts |
Database instance, shared servers
|
DRnn
|
ASM Disk Resynchronization Slave
Process
|
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.
|
ASM Instance
|
DSKM
|
Slave Diskmon Process
|
Acts as the 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.
|
ASM instance, Exadata
|
DWnn
|
Data Pump Worker Process
|
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.
|
Database instance
|
EMNC
|
EMON Coordinator Process
|
Coordinates database event
management and notifications
|
EMNC coordinates event management
and notification activity in the database, including Streams Event
Notifications, Continuous Query Notifications, and Fast Application
Notifications.
|
Database and ASM instances
|
Ennn
|
EMON Slave Process
|
Performs database event
management and notifications
|
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.
|
Database and ASM instances
|
FBDA
|
Flashback Data Archiver Process
|
Archives historical rows for
tracked tables into flashback data archives and manages archive space,
organization, and retention
|
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.See Also: Oracle Database Advanced Application Developer's Guide |
Database and ASM instances
|
FMON
|
File Mapping Monitor Process
|
Manages mapping information for
the Oracle Database file mapping interface
|
The
FMON is started by the database whenever the DBMS_STORAGE_MAP package enables you to control 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.FILE_MAPPING initialization parameter is set to true . |
Database and ASM instances
|
FSFP
|
Data Guard Broker Fast Start
Failover Pinger Process
|
Maintains fast-start failover
state between the primary and target standby databases
|
FSFP is created when fast-start
failover is enabled.
|
Database instance, Data Guard
|
Global Conflict Resolution Slave
Process
|
Performs synchronous tasks on
behalf of LMHB
|
GCRn processes are transient slaves that
are started and stopped as required by LMHB to perform synchronous or
resource intensive tasks.
|
Database and ASM instances,
Oracle RAC
|
|
GEN0
|
General Task Execution Process
|
Performs required tasks including
SQL and DML
|
Database and ASM instances
|
|
GMON
|
ASM Disk Group Monitor Process
|
Monitors all mounted ASM disk
groups
|
GMON monitors all the 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.
|
ASM instance
|
GTXn
|
Global Transaction Process
|
Provides transparent support for
XA global transactions in an Oracle RAC environment
|
These processes help maintain the
global information about XA global transactions throughout the cluster. Also,
the processes help perform two-phase commit for global transactions anywhere
in the cluster so that an Oracle RAC database behaves as a single system to
the 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.See Also: Oracle Real Application Clusters Administration and Deployment Guide |
Database instance, Oracle RAC
|
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
|
I/O slave process can be
configured on platforms where asynchronous I/O support is not available.
These slaves are started by setting the corresponding slave enable parameter
in the server parameter file. The I/O slaves simulate the asynchronous I/O
behavior when the underlying platform does not have native support for
asynchronous I/O.
|
Database instance
|
INSV
|
Data Guard Broker Instance Slave
Process
|
Performs Data Guard broker
communication among instances in an Oracle RAC environment
|
INSV is created when the
DG_BROKER_START initialization parameter is set totrue . |
Database instance, Data Guard
|
Jnnn
|
Job Queue Slave Process
|
Executes jobs assigned by the job
coordinator
|
Job slave processes are created
or awakened by the job coordinator when it is time for a job to be executed.
Job slaves gather all the metadata required to run the job from the data
dictionary. The slave processes start a database session as the owner of the
job, execute triggers, and then execute the job. After the job is complete,
the slave processes commit and then execute appropriate triggers and close
the session. The slave can repeat this operation in case additional jobs need
to be run. |
Database instance
|
LCK0
|
Instance Enqueue Background
Process
|
Manages global enqueue requests
and cross-instance broadcasts
|
The process handles all requests
for resources other than data blocks. For examples, LCK0 manages library and
row cache requests.
|
Database and ASM instances,
Oracle RAC
|
LGWR
|
Log Writer Process
|
Writes redo entries to the online
redo log
|
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 a group of redo log files.
See Also: Oracle Database Concepts and Oracle Database Administrator's
Guide |
Database and ASM instances
|
LMD0
|
Global Enqueue Service Daemon 0
Process
|
Manages incoming remote resource
requests from other instances
|
LMD0 processes enqueue resources
managed under Global Enqueue Service. In particular, LMD0 processes incoming
enqueue request messages and controls access to global enqueues. It also
performs distributed deadlock detections.
|
Database and ASM instances,
Oracle RAC
|
LMHB
|
Global Cache/Enqueue Service
Heartbeat Monitor
|
Monitor the heartbeat of LMON,
LMD, and LMSnprocesses
|
LMHB monitors LMON, LMD, and LMSn processes
to ensure they are running normally without blocking or spinning.
|
Database and ASM instances,
Oracle RAC
|
LMON
|
Global Enqueue Service Monitor
Process
|
Monitors an Oracle RAC cluster to
manage global resources
|
LMON maintains instance
membership within Oracle RAC. The process detects instance transitions and
performs reconfiguration of GES and GCS resources.
See Also: Oracle Real Application Clusters
Administration and Deployment Guide |
Database and ASM instances,
Oracle RAC
|
LMSn
|
Global Cache Service Process
|
Manages resources and provides
resource control among Oracle 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.
See Also: Oracle Real Application Clusters
Administration and Deployment Guide |
Database and ASM instances,
Oracle RAC
|
LSP0
|
Logical Standby Coordinator
Process
|
Schedules transactions for Data
Guard SQL Apply
|
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.
|
Database instance, Data Guard
|
LSP1
|
Logical Standby Dictionary Build
Process
|
Performs a logical standby
dictionary build on a primary database
|
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.
|
Database instance, Data Guard
|
LSP2
|
Logical Standby Set Guard Process
|
Determines which database objects
will be protected by the database guard
|
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.
|
Database instance, Data Guard
|
Lnnn
|
Pooled Server Process
|
Handles 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.
See Also: Oracle Database Concepts |
Database instance, Database
Resident Connection Pooling
|
MARK
|
Mark AU for Resynchronization
Coordinator Process
|
Marks ASM allocation units as
stale following a missed write to an offline disk
|
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.
|
Database and ASM instances
|
MMAN
|
Memory Manager Process
|
Serves as the instance memory
manager
|
This process performs the
resizing of memory components on the instance.
|
Database and ASM instances
|
MMNL
|
Manageability Monitor Lite
Process
|
Performs tasks relating to
manageability, including active session history sampling and metrics
computation
|
MMNL performs many tasks relating
to manageability, including session history capture and metrics computation.
|
Database and ASM instances
|
MMON
|
Manageability Monitor Process
|
Performs or schedules many
manageability tasks
|
MMON performs many tasks related
to manageability, including taking Automatic Workload Repository snapshots
and performing Automatic Database Diagnostic Monitor analysis.
|
Database and ASM instances
|
Mnnn
|
MMON Slave Process
|
Performs manageability tasks on
behalf of MMON
|
Mnnn performs manageability tasks
dispatched to them by MMON. Tasks performed include taking Automatic Workload
Repository snapshots and Automatic Database Diagnostic Monitor analysis.
|
Database and ASM instances
|
MRP0
|
Managed Standby Recovery Process
|
Coordinates the application of
redo on a physical standby database
|
MRP0 is spawned at the start of
redo apply on a physical standby database. This process handles the
extraction of redo and coordinates the application of that redo on a physical
standby database.
See Also: Oracle Data Guard Concepts and
Administration |
Database instance, Data Guard
|
MSnn
|
LogMiner Worker Process
|
Reads redo log files and
translates and assembles into transactions
|
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.
|
Database instance, Logical
Standby, Oracle Streams
|
Nnnn
|
Connection Broker Process
|
Monitors idle connections and
hands off active connections 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.
See Also: Oracle Database Concepts |
Database instance, Database
Resident Connection Pooling
|
NSAn
|
Redo Transport NSA1 Process
|
Ships redo from current online
redo logs to remote standby destinations configured for ASYNC transport
|
NSAn can run as multiple processes, where n is 1-9 or A-V.
See Also: Oracle Data Guard Concepts and
Administration |
Database instance, Data Guard
|
NSSn
|
Redo Transport NSS1 Process
|
Acts as a slave for LGWR when
SYNC transport is configured for a remote standby destination
|
NSSn can run as multiple processes, where n is 1-9 or A-V.
See Also: Oracle Data Guard Concepts and
Administration |
Database instance, Data Guard
|
NSVn
|
Data Guard Broker NetSlave
Process
|
Performs broker network
communications between databases in a Data Guard environment
|
NSVn is 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.
|
Database instance, Data Guard
|
OCFn
|
ASM CF Connection Pool Process
|
Maintains a connection to the ASM
instance for metadata operations
|
Database and ASM instances
|
|
Onnn
|
ASM Connection Pool Process
|
Maintains a connection to the ASM
instance for metadata operations
|
Onnn slave processes are spawned on
demand. These processes communicate with the ASM instance.
|
Database and ASM instances
|
PING
|
Interconnect Latency Measurement
Process
|
Assesses latencies associated
with communications for each pair of cluster instances
|
Every few seconds, the process in
one instance sends messages to each instance. The message is received by PING
on the target instance. The time for the round trip is measured and
collected.
|
Database and ASM instances,
Oracle RAC
|
PMON
|
Process Monitor
|
Monitors the other background
processes and performs process recovery when a server or dispatcher process
terminates abnormally
|
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.See Also: Oracle Database Concepts and Oracle Database Net Services Administrator's Guide |
Database and ASM instances
|
Pnnn
|
Parallel Query Slave Process
|
Perform parallel execution of a
SQL statement (query, DML, or DDL)
|
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 Pnnn processes is controlled by the
initialization parameter PARALLEL_MAX_SERVERS . Slave processes
are numbered from 0 to the PARALLEL_MAX_SERVERS setting. If the query is a GV$ query, then these background processes
are numbered backward, starting from PZ99. |
Database and ASM instances
|
PRnn
|
Parallel Recovery Process
|
Performs tasks assigned by the
coordinator process performing parallel recovery
|
PRnn serves as a slave process for the
coordinator process performing parallel media recovery and carries out tasks
assigned by the coordinator. The default number of these processes is based
on number of CPUs.
|
Database instance
|
PSP0
|
Process Spawner Process
|
Spawns Oracle background
processes after initial instance startup
|
Database and ASM instances
|
|
QMNC
|
AQ Coordinator Process
|
Monitors AQ
|
QMNC is 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
adversely affected . |
Database instance, Advanced
Queuing
|
Qnnn
|
AQ Server Class Process
|
Performs various AQ-related
background task for QMNC
|
Qnnn acts as a slave process for QMNC and
carry out tasks assigned by QMNC. The number of these processes is
dynamically managed by QMNC based on load.
|
Database instance
|
RBAL
|
ASM Rebalance Master Process
|
Coordinates rebalance activity
|
In an ASM instance, it
coordinates rebalance activity for disk groups. In a database instances, it
manages ASM disk groups.
|
Database and ASM instances
|
RCBG
|
Result Cache Background Process
|
Handles result cache messages
|
This process is used for handling
invalidation and other messages generated by server processes attached to
other instances in Oracle RAC.
|
Database instance, Oracle RAC
|
RECO
|
Recoverer Process
|
Resolves distributed transactions
that are pending because of a network or system failure in a distributed
database
|
RECO uses the information in the
pending transaction table to finalize the status of in-doubt transactions. At
timed intervals, the local RECO attempts to connect to remote databases and
automatically complete the commit or rollback of the local portion of any
pending distributed transactions. All transactions automatically resolved by
RECO are removed from the pending transaction table.
See Also: Oracle Database Concepts and Oracle Database Net Services
Administrator's Guide |
Database instance
|
RMSn
|
Oracle RAC Management Process
|
Performs manageability tasks for
Oracle RAC
|
RMSn performs a variety of tasks,
including creating resources related to Oracle RAC when new instances are
added to a cluster.
See Also: Oracle Real Application Clusters
Administration and Deployment Guide |
Database instance, Oracle RAC
|
Rnnn
|
ASM Block Remap Slave Process
|
Remaps a block with a read error
|
A database instance reading from
an ASM disk group can encounter an error during a read. If possible, ASM
asynchronously schedules a Rnnn slave process to remap this bad
block from a mirror copy.
|
ASM instance
|
RPnn
|
Capture Processing Worker Process
|
Processes a set of workload
capture files
|
RPnn are worker processes spawned by
calling
Worker processes execute in parallel without needing to communicate with
each other. After each process is finished processing its assigned files, it
exits and informs its parent process.DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE(capture_dir,parallel_level) .
Each worker process is assigned a set of workload capture files to process.The number of worker processes is controlled by the parallel_level parameter
of DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE .
By default,parallel_level is null. Then, the number of worker
processes is computed as follows:SELECT VALUE
FROM V$PARAMETER
WHERE NAME='cpu_count';
When parallel_level is 1 , no worker processes are spawned. |
Database instance
|
RSM0
|
Data Guard Broker Worker Process
|
Performs monitoring management
tasks related to Data Guard on behalf of DMON
|
The process is created when a
Data Guard broker configuration is enabled.
|
Database instance, Data Guard
|
RSMN
|
Remote Slave Monitor Process
|
Manages background slave process
creation and communication on remote instances in Oracle RAC
|
This background process manages
the creation of slave processes and the communication with their coordinators
and peers. These background slave processes perform tasks on behalf of a
coordinating process running in another cluster instance.
|
Database instance, Oracle RAC
|
RVWR
|
Recovery Writer Process
|
Writes flashback data to the
flashback logs in the flash recovery area
|
RVWR writes flashback data from
the flashback buffer in the SGA to the flashback logs. RVWR also creates
flashback logs and performs some tasks for flashback log automatic
management.
|
Database instance, Flashback
Database
|
SMCO
|
Space Management Coordinator
Process
|
Coordinates the execution of
various space management tasks
|
This background process
coordinates the execution of various space management tasks, including
proactive space allocation and space reclamation. SMCO dynamically spawns
slave processes (Wnnn) to implement these
tasks.
|
Database instance
|
SMON
|
System Monitor Process
|
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
|
SMON performs many database
maintenance tasks, including the following:
·
Creates and manages the temporary tablespace
metadata
·
Reclaims space used by orphaned temporary
segments
·
Maintains the undo tablespace by onlining,
offlining, and shrinking the undo segments based on undo space usage
statistics
·
Cleans up the data dictionary when it is in a
transient and inconsistent state
·
Maintains the SCN to time mapping table used
to support Oracle Flashback features
In an Oracle RAC database, the SMON process of one instance can perform
instance recovery for other instances that have failed.SMON is resilient to internal and external errors raised during background activities. See Also: Oracle Database Concepts |
Database instance
|
Snnn
|
Shared Server Process
|
Handles client requests 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 .See Also: Oracle Database Concepts |
Database instance, shared servers
|
TEMn
|
ASM disk Test Error Emulation
Process
|
Emulates I/O errors on ASM disks
through named events
|
I/O errors can be emulated on ASM
disk I/O through named events. The scope can be the process, instance, or even
cluster. Optionally, a set of AUs can be chosen for error emulation.
|
ASM instance
|
VBGn
|
Volume Background Process
|
Communicates between the ASM
instance and the operating system volume driver
|
VBGn handles messages originating from
the volume driver in the operating system and sends them to the ASM instance.
VBGn can
run as multiple processes, where n is
0-9. |
ASM instance
|
VDBG
|
Volume Driver Process
|
Forwards ASM requests to perform
various volume-related tasks
|
VDBG 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.
|
ASM instance
|
VKRM
|
Virtual Scheduler for Resource
Manager Process
|
Serves as centralized scheduler
for Resource Manager activity
|
VKRM manages the CPU scheduling
for all managed Oracle processes. The process schedules managed processes in
accordance with an active resource plan.
|
Database instance
|
VKTM
|
Virtual Keeper of Time Process
|
Provides a wall clock time and
reference time for time interval measurements
|
VKTM acts as a time publisher for
an Oracle instance. VKTM publishes two sets of time: 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.
|
Database and ASM instances
|
VMB0
|
Volume Membership Process
|
Maintains cluster membership on
behalf of the ASM volume driver
|
This process membership in the
cluster as an I/O-capable client on behalf of the ASM volume driver.
|
ASM instance
|
Vnnn
|
ASM Volume I/O Slave Process
|
Initializes ASM volume contents
during creation
|
This process is responsible for
initializing the ASM volume during creation.
|
ASM instance
|
Wnnn
|
Space Management Slave Process
|
Performs various background space
management tasks, including proactive space allocation and space reclamation
|
Wnnn processes are slave processes
dynamically spawned by SMCO to perform space management tasks in the background.
These tasks include preallocating space into locally managed tablespace and
SecureFiles segments based on space usage growth analysis, and reclaiming
space from dropped segments. At most 10 Wnnn slaves can run on one database
instance. After being started started, the slave acts as an autonomous agent.
After it finishes task execution, it automatically picks up another task from
the queue. The process terminates itself after being idle for a long time.
|
Database instance
|
XDMG
|
Exadata Automation Manager
|
Initiates automation tasks
involved in managing Exadata storage
|
XDMG 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.
|
ASM instance, Exadata
|
XDWK
|
Exadata Automation Manager
|
Performs automation tasks
requested by XDMG
|
XDWK gets 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.
|
ASM instance, Exadata
|
Xnnn
|
ASM Disk Expel Slave Process
|
Performs ASM post-rebalance activities
|
This process expels dropped disks
at the end of an ASM rebalance.
|
No comments :
Post a Comment