New Background Processes In 11g

*  ACMS (atomic controlfile to memory service) per-instance process is an agent that contributes to ensuring a distributed SGA memory update is either globally committed on success or globally aborted in the event of a failure in an Oracle RAC environment.

*  DBRM (database resource manager) process is responsible for setting resource plans and other resource manager related tasks.This process implements the resource plans that may be configured for a database instance. It sets the resource plans in place and performs various operations related to enforcing/implementing those resource plans. The resource manager allows the administrators of a database to have fine grained control over the resources used by the database instance, by applications accessing the database, or by individual users accessing the database.

*  DIA0 (diagnosability process 0) (only 0 is currently being used) is responsible for hang detection and deadlock resolution.

*  DIAG (diagnosability) process performs diagnostic dumps and executes global oradebug commands.In past releases, the DIAG process was used exclusively in a RAC environment. As of Oracle Database 11g, with the new ADR (Advanced Diagnostic Repository), it is responsible for monitoring the overall health of the instance, and it captures information needed in the processing of instance failures. This applies to both single instance configurations as well as multi-instance RAC configurations.

*  EMNC (event monitor coordinator) is the background server process used for database event management and notifications.The EMNC process is part of the AQ architecture. It is used to notify queue subscribers of messages they would be interested in. This notification is performed asynchronously. There are Oracle Call Interface (OCI) functions available to register a callback for message notification. The callback is a function in the OCI program that will be invoked automatically whenever a message of interest is available in the queue.The EMNn background process is used to notify the subscriber. The EMNC process is started automatically
when the first notification is issued for the instance. The application may then issue an explicit message_receive(dequeue) to retrieve the message.

*  FBDA (flashback data archiver process) archives the historical rows of tracked tables into flashback data archives. Tracked tables are tables which are enabled for flashback archive. When a transaction containing DML on a tracked table commits, this process stores the pre-image of the rows into the flashback archive. It also keeps metadata on the current rows.FBDA is also responsible for automatically managing the flashback data archive for space, organization, and retention and keeps track of how far the archiving of tracked transactions has occurred.This process is new in Oracle Database 11g Release 1 and above. It is the key component of the new flashback data archive capability–the ability to query data “as of” long periods of time ago (for example, to query data in a table as it appeared one year ago, five years ago, and so on). This long term historical query capability is achieved by maintaining a history of the row changes made to every row in a table over time. This history, in turn, is maintained by the FBDA process in the background. This process functions by working soon after a transaction commits. The FBDA process will read the UNDO generated by that transaction and roll back the changes made by the transaction. It will then record these rolled back (the original values) rows in the flashback data archive for us.

*  GTX0-j (global transaction) processes provide transparent support for XA global transactions in an Oracle RAC environment. The database autotunes the number of these processes based on the workload of XA global transactions. Global transaction processes are only seen in an Oracle RAC environment.

*  KATE performs proxy I/O to an ASM metafile when a disk goes offline.

*  MARK marks ASM allocation units as stale following a missed write to an offline disk.

*  SMCO (space management coordinator) process coordinates the execution of various space management related tasks, such as proactive space allocation and space reclamation. It dynamically spawns slave processes (Wnnn) to implement the task.This process is part of the manageability infrastructure. It coordinates the proactive space management features of the database such as the processes that discover space that could be reclaimed and the processes that perform the reclamation.

*  VKTM (virtual keeper of time) is responsible for providing a wall-clock time (updated every second) and reference-time counter (updated every 20 ms and available only when running at elevated priority).Implements a consistent, fine-grained clock
for the Oracle instance. It is responsible for providing both wall clock time (human readable) as well as an extremely high resolution timer (not necessarily built using wall clock time, more of a ticker that increments for very small units of time) used to measure durations and intervals.

*  RCBG – this background process is responsible for processing data into server result cache

*  GEN0 – General task execution process which performs required tasks;This process provides, as expected by its name, a general task execution thread for the database. The main goal of this process is to offload potentially blocking processing (processing that would cause a process to stop while it occurs) from some other process and perform it in the background. For example, if the main ASM process needs to perform some blocking file operation, but that operation could safely be done in the background (ASM can safely continue processing before the operation completes), then the ASM process may request the GEN0 process to perform this operation and let GEN0 notify it upon completion. It is similar in nature to the slave processes described further below.

*  INSV Data Guard Broker INstance Slave Process; The internode servers(INSVs) maintain a connection between the nodes in the cluster to ensure that Broker on each node knows the state of the cluster. The primary database will always startup an INSV process even if the database is not a RAC; As other RAC instances start,the Broker will start the INSVs, and they will make queries between all the instances to determine the current state of each node in a Broker-controlled database. In this manner, the Broker is able to maintain information about each instance in the RAC. To make sure that this does not have a adverse impact to performance , this querying is optimized to avoid any unnecessary RAC traffic.

*  FSFP Data Guard Broker FSFO Pinger; We may see one more process on the primary database in Broker-controlled configuration: The Fast-Start Failover process(FSFP) which is used only when the primary is under the control of DataGurad’s automatic failover feature, Fast-Start Failover. The FSFP process will establish a connection to the Fast-Start Failover target database by connecting to a DRC process on that database, much like the NVS to DRC process connection.

* NSVn DataGuard Net Server(Nsvn) From 1 to n of these network server processes can exist. They are responsible for making contact with the remote database and sending across any work items to the remote database. Connection to the remote database are made using the same connect identifier that you specified for the database when you created the configuration. “DMON communicates with the standby databases using NSV processes. This prevents DMON from network hang.”

* DRCn These network receiver processes establish the connection from the source database NSVn process. An NSVn to DRCn connection is similar to the LogWriter Network Service(LSN) to the Remote File Servers(RFS) connection for Redo Transport. As with Redo Transport , when the Broker needs to send something(data or SQL, for example) between databases, it uses this NSV to DRC connection. These connections are started as need.

*  XDMG cell automation manager;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.

* XDWK 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.

*  ABMR Auto BMR Background Process “In addition to the real time query capability of the 11g Active Data Guard feature, we can also add to our high availability capability by using the Automatic Block Media Repair feature whereby data block corruptions on the Primary database can be repaired by obtaining those blocks from the standby site – all performed by a background process (ABMR) transparent to the application.”

Some additional Processes not documented in 10G :

* PZ (PQ slaves used for global Views) are RAC Parallel Server Slave processes, but they are not normal parallel slave processes, PZnn processes (starting at 99) are used to query GV$ views which is done using Parallel Execution on all instances, if more than one PZ process is needed, then PZ98, PZ97,… (in that order) are created automatically.

* O00 (ASM slave processes) A group of slave processes establish connections to the ASM instance. Through this connection pool database processes can send messages to the ASM instance. For example opening a file sends the open request to the ASM instance via a slave. However slaves are not used for long running operations such as creating a file. The use slave (pool) connections eliminate the overhead of  logging into the ASM instance for short requests

* x000 – Slave used to expell disks after diskgroup reconfiguration

DESCRIPTION	DEST
Auto BMR Listener	ABMR
Auto BMR message	ABMR
ACMS Watchdog Task	ACMS
RM workload learning	DBRM
Check for MDBRM to LDBRM message	DBRM
Check for LDBRM to MDBRM message	DBRM
DBRM Active Session Limit Event	DBRM
Check queuing policy	DBRM
RM running count check	DBRM
DBRM Timeout Actions	DBRM
shutdown DBRM	DBRM
do RM action in DBRM	DBRM
check for quiesce messages	DBRM
unquiesce the instance during database close	DBRM
unsubscribe to quiesce channel	DBRM
subscribe to quiesce channel	DBRM
IORM action	DSKM
DSKM check for message from master DiskMon	DSKM
SAGE CC Action	DSKM
DSKM action	DSKM
FSFP Wakeup	FSFP
FSFP Shutdown Message	FSFP
FSFP Register Observer Message	FSFP
ASM UFG health check timeout	GEN0
Diskgroup Resource Action	GEN0
release quiesce enqueue	GEN0
get quiesce enqueue	GEN0
check for parameters from other instances	GEN0
kcl downconvert object locks	GEN0
kcl update persistent read mostly info	GEN0
kcl initiate persistent read mostly	GEN0
kcb L2 cache verify file header	GEN0
Start Exadata specific backgrounds	GEN0
KSVMSVC timeout action	GEN0
Heartbeat action for HSM connectivity	GEN0
Prepare flashback log	GEN0
GEN0 Timeout KCQ cleanup	GEN0
Global Txn SHUTdown	GTX*
K2Q Timeout action	GTX*
get instance lock	GTX*
convert instance lock	GTX*
free instance lock	GTX*
INSV Receive Message	INSV
INSV Shutdown Message	INSV
INSV Interrupt	INSV
Network Server forced	NS**
Network Server shutdown	NS**
Network Server wakeup	NSA*
Network Server wakeup	NSS*
NetSlave Interrupt Function	NSV*
NetSlave Wakeup Message	NSV*
NetSlave Shutdown Message	NSV*
do work for new gpnp instances	RMS0
RSM Set Parameter	RSM0
RSM Wakeup	RSM0
RSM Receive Message	RSM0
SMCO Timout	SMCO
SMCO Action	SMCO
Infrequent timeout actions for Exadata disks auto manage module	XDMG
Action to process msgs from instance processes	XDMG
Interrupt actions for Exadata disks auto manage module	XDMG

References:
F Background Processes
<Oracle Data Guard 11g Handbook>
<Oracle Database 9i, 10g, and 11g Programming Techniques and Solutions>
New Background Processes In 11g [ID 444149.1]