Cold backup and cloning

1.  Check the Database open or not.

    2.       For cold backup Archive Log mode is no need, we can do with No Archive Log mode itself.

    3.       First we need to take the backup of control file.

SQL>alter database backup controlfile to trace as ‘/opt/backup/control_file_backup.sql’

    4.       Shutdown the Database.

    5.       We need to create the directory structure for TARGET like as same as SOURCE.

(In my case SOURCE db name is orcl, TARGET name is test)

    6.       Copy the SOURCE pfile (/opt/oracle/admin/orcl/pfile) to TARGET (/opt/oracle/admin/test/pfile).

    7.       Edit the pfile according to TARGET

(escape:%s/orcl/test/g)

    8.       Copy the all .dbf, .log from SOURCE (/opt/oracle/oradata/orcl) to TARGET  (/opt/oracle/oradata/test ).

    9.       Find the oracle SID,

$echo $ORACLE_SID

   10.   Export the current sid to TARGET sid,

$export ORACLE_SID=test

   11.   Next with the help of control file backup, we need to create the control files for TARGET, for that we need to edit the control file backup according to test.

$vi /opt/backup/control_file_backup.sql

(escape:%s/orcl/test/g)

(escape:%s/ORCL/TEST/g)

   12.   Connect the sqlplus & startup with TARGET database pfile & with nomount state.

$startup pfile=’/opt/oracle/admin/test/pfile/initTEST.ora’ nomount;

   13.   Execute the control file,

SQL>@/opt/backup/ control_file_backup.sql

   14.   Then we need to recover the Database with the help of the control file.

recover database using backup controlfile;

   15.   Apply the redo log files.

   16.   After reached the current log file, it will show Media Recovery Completed.

   17.   Then open the db with resetlogs,

SQL>alter database open resetlogs;

Hot backup and cloning

1.       For Hot backup we have to put the Database in Archive Log mode.

$startup mount

SQL>alter database archivelog;

    2.       Next we need to take the backup of control file.

SQL>alter database backup controlfile to trace as ‘/opt/backup/control_file_backup.sql’

    3.       Then, we need to put the Database in backup mode,

SQL>alter database begin backup;

(If the database in backup mode, all the transactions will go to the archive log. But in my case, all the transactions saved in redo logs, since its empty, so I did,)

 SQL>alter system archive log current;

    4.       We need to create the directory structure for TARGET like as same as SOURCE.

(In my case SOURCE db name is orcl, TARGET name is test)

    5.       Copy the SOURCE pfile (/opt/oracle/admin/orcl/pfile) to TARGET (/opt/oracle/admin/test/pfile).

    6.       Edit the pfile according to TARGET

(escape:%s/orcl/test/g)

    7.       Copy only .dbf from SOURCE (/opt/oracle/oradata/orcl) to TARGET (/opt/oracle/oradata/test ).

    8.       Once the datafile copying is finished, we have to end the database backup mode,

SQL>alter database end backup;

    9.       Find the oracle SID,

$echo $ORACLE_SID

   10.   Export the current sid to TARGET sid,

$export ORACLE_SID=test

   11.   Next with the help of control file backup, we need to create the control files for TARGET, for that we need to edit the control file backup according to test.

$vi /opt/backup/control_file_backup.sql

(escape:%s/orcl/test/g)

(escape:%s/ORCL/TEST/g)

   12.   Connect the sqlplus & startup with TARGET database pfile & with nomount state.

$startup pfile=’/opt/oracle/admin/test/pfile/initTEST.ora’ nomount;

   13.   Execute the control file,

SQL>@/opt/backup/ control_file_backup.sql

   14.   Then we need to recover the Database with the help of the control file.

SQL>recover database using backup controlfile;

   15.   Apply the archive log files.

   16.   After reached the current archive log file, it will show Media Recovery Completed.

   17.   After applying all Archive files, still it didn’t show Media Recovery Completed, then apply the redo log files.

   18.   Then open the db with resetlogs,

alter database open resetlogs;

Oracle background processes

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.

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.

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.

Oracle Real Application Clusters (RAC) Background Processes

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

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

LCKx - This process manages the global enqueue requests and the cross-instance broadcast. Workload is automatically shared and balanced when there are multiple Global Cache Service Processes (LMSx).

LMON - The Global Enqueue Service Monitor (LMON) monitors the entire cluster to manage the global enqueues and the resources. LMON manages instance and process failures and the associated recovery for the Global Cache Service (GCS) and Global Enqueue Service (GES). In particular, LMON handles the part of recovery associated with global resources. LMON-provided services are also known as cluster group services (CGS)

LMDx - The Global Enqueue Service Daemon (LMD) is the lock agent process that manages enqueue manager service requests for Global Cache Service enqueues to control access to global enqueues and resources. The LMD process also handles deadlock detection and remote enqueue requests. Remote resource requests are the requests originating from another instance.

LMSx - The Global Cache Service Processes (LMSx) are the processes that handle remote Global Cache Service (GCS) messages. Real Application Clusters software provides for up to 10 Global Cache Service Processes. The number of LMSx varies depending on the amount of messaging traffic among nodes in the cluster.

The LMSx handles the acquisition interrupt and blocking interrupt requests from the remote instances for Global Cache Service resources. For cross-instance consistent read requests, the LMSx will create a consistent read version of the block and send it to the requesting instance. The LMSx also controls the flow of messages to remote instances.

The LMSn processes handle the blocking interrupts from the remote instance for the Global Cache Service resources by:

• Managing the resource requests and cross-instance call operations for the shared resources.
   
• Building a list of invalid lock elements and validating the lock elements during recovery.
   
• Handling the  global lock deadlock detection and Monitoring for the lock conversion timeouts

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 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 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. 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 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 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 V$STREAMS_CAPTURE view for information about this background process. See Also: Oracle Streams Concepts and Administration	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 theDBMS_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 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. FMON is started by the database whenever the 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
GCRnFoot 1	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 callingDBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE(capture_dir,parallel_level). Each worker process is assigned a set of workload capture files to process. 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. The number of worker processes is controlled by the parallel_levelparameter 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.