Monday , September 25 2017
Home / Oracle DBA / Overview of Background Processes

Overview of Background Processes

Overview of Background Processes

Process Monitor Process (PM ON)
The process monitor (PM ON) monitors the other background processes and performs process recovery when a server or dispatcher process terminates abnormally. PM ON is responsible for cleaning up the database buffer cache and freeing resources that the client process was using.
System Monitor Process (SM ON)
The system monitor process (SM ON) is in charge of a variety of system-level clean up duties. The duties assigned to SM ON include:
Performing instance recovery, if necessary,  at instance startup.
Recovering terminated transactions that were skipped during instance recovery because of file-read or table space offline errors. SM ON recovers the transactions when the table space or file is brought back online.
Cleaning up unused temporary segments.
Coalescing contiguous free extents within dictionary-managed table spaces. SM ON checks regularly to see whether it is needed. Other processes can call SM ON if they detect a need for it.
Database Writer Process (DBW n)
The database writer process (DBW n) writes the contents of database buffers to data files. DBW n processes write modified buffers in the database buffer cache to disk. Although one database writer process (DBW0) is adequate for most systems, you can configure additional processes—DBW1 through DBW9 and DBW a through DBW j—to improve write performance if your system modifies data heavily. The DBW n process writes dirty buffers to disk under the following conditions:
When a server process cannot find a clean reusable buffer after scanning a threshold number of buffers.
DBW n periodically writes buffers to advance the checkpoint, which is the position in the redo thread from which instance recovery begins. The log position of the checkpoint is determined by the oldest dirty buffer in the buffer cache.
Log Writer Process (LGWR)
The log writer process (LGWR) manages the redo log buffer. LGWR writes one contiguous portion of the buffer to the online redo log. By separating the tasks of modifying database buffers, performing scattered writes of dirty buffers to disk, and performing fast sequential writes of redo to disk, the database improves performance.
In the following circumstances, LGWR writes all redo entries that have been copied into the buffer since the last time it wrote:
A user commits a transaction
An online redo log switch occurs.
Three seconds have passed since LGWR last wrote.
The redo log buffer is one-third full or contains 1 MB of buffered data.
DBW n must write modified buffers to disk.
Before DBW n can write a dirty buffer, redo records associated with changes to the buffer must be written to disk (the write-ahead protocol). If DBW n finds that some redo records have not been written, it signals LGWR to write the records to disk and waits for LGWR to complete before writing the data buffers to disk.
Checkpoint Process (CKPT)
The checkpoint process (CKPT) updates the control file and data file headers with checkpoint information and signals DBW n to write blocks to disk. Check point information includes the checkpoint position, SCN, location in online redo log to begin recovery, and so on.
Note: LGWR can write redo log entries to disk before a transaction commits. The redo entries become permanent only if the transaction later commits.
Manageability Monitor Processes (MMON and MMNL)
The manageability monitor process (MMON) performs many tasks related to the Automatic Workload Repository (AWR). For example, MMON writes when a metric violates its threshold value, taking snapshots, and capturing statistics value for recently modified SQL objects.
The manageability monitor lite process (MMNL) writes statistics from the Active Session History (ASH) buffer in the SGA to disk. MMNL writes to disk when the ASH buffer is full.
Recover-er Process (RECO)
In a distributed database, the recover-er process (RECO) automatically resolves failures in distributed transactions. The RECO process of a node automatically connects to other databases involved in an in-doubt distributed transaction. When RECO reestablishes a connection between the databases, it automatically resolves all in-doubt transactions, removing from each database’s pending transaction table any rows that correspond to the resolved transactions.
Archiver Processes (ARC n)
The archiver processes (ARC n) copy online redo log files to offline storage after a redo log switch occurs. These processes can also collect transaction redo data and transmit it to standby database destinations. ARC n processes exist only when the database is in ARCHIVELOG mode and automatic archiving is enabled.
Flashback Data Arc hiver Process (FBDA)
The flashback data arc hiver process (FBDA) archives historical rows of tracked tables into Flashback Data Archives. When a transaction containing DML on a tracked table commits, this process stores the pre-image of the rows into the Flashback Data Archive. It also keeps metadata on the current rows. FBDA automatically manages the flashback data archive for space, organization, and retention. Additionally, the process keeps track of how far the archiving of tracked transactions has occurred.
Space Management Coordinator Process (SMCO)
The SMCO process coordinates the execution of various space management related tasks, such as proactive space allocation and space reclamation. SMCO dynamically spawns slave processes (W nnn) to implement the task.
View More:
Overview of Diagnostic Files
Overview of Oracle Parameter Files
Oracle System Identifier (SID)



Check Also

How to switch on primary database to physical standby database

After configuration data guard then data is switching  into primary database  to standby database : …

Leave a Reply

Your email address will not be published. Required fields are marked *