The mandatory background processes are present in all typical database configurations. These processes run by default in a database instance started with a minimally configured initialization parameter file.
This section describes the following mandatory background processes:
Process Monitor Process (PMON)
System Monitor Process (SMON)
Database Writer Process (DBWn)
Log Writer Process (LGWR)
Checkpoint Process (CKPT)
Manageability Monitor Processes (MMON and MMNL)
Recoverer Process (RECO)
Process Monitor Process (PMON):
1. Monitors the other background processes and performs process recovery when a server or dispatcher process terminates abnormally
2. Responsible for cleaning up the database buffer cache and freeing resources that the client process was using
3. Resets the status of the active transaction table
4. Releases locks that are no longer required
5. Removes the process ID from the list of active processes
6. Registers information about the instance and dispatcher processes with the Oracle Net listener
7. When an instance starts, PMON polls the listener to determine whether it is running. If the listener is running, then PMON passes it relevant parameters. If it is not running, then PMON periodically attempts to contact it.
System Monitor Process (SMON):
1. Responsible for system-level cleanup
2. Performs instance recovery, if necessary, at instance startup.
3. If its RAC Database, the SMON process of one database instance can perform instance recovery for a failed instance.
4. Cleaning up unused temporary segments.
5. Coalescing contiguous free extents within dictionary-managed tablespaces.
Database Writer Process (DBWn)
1. DBWn writes the contents of database buffers to data files. DBWn processes write modified buffers in the database buffer cache to disk
2. Although one database writer process (DBW0) is adequerfect ate for most systems, you can configure additional processes—DBW1 through DBW9 and DBWa through DBWj—to improve write performance if your system modifies data heavily however these additional DBWn processes are not useful on uniprocessor systems.
The DBWn process writes dirty buffers to disk under the following conditions:
1. When a server process cannot find a clean reusable buffer after scanning a threshold number of buffers, it signals DBWn to write. DBWn writes dirty buffers to disk asynchronously if possible while performing other processing.
2. DBWn 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.
Note: 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.
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.
In the following circumstances, LGWR writes all redo entries that have been copied into the buffer since the last time it wrote:
1. A user commits a transaction
2. An online redo log switch occurs
3. Three seconds have passed since LGWR last wrote
4. The redo log buffer is one-third full or contains 1 MB of buffered data.
5. DBWn must write modified buffers to disk
Note: Before DBWn can write a dirty buffer, redo records associated with changes to the buffer must be written to disk (the write-ahead protocol). If DBWn 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.
Relation between LGWR and Commits:
Oracle Database uses a fast commit mechanism to improve performance for committed transactions. When a user issues a COMMIT statement, the transaction is assigned a system change number (SCN). LGWR puts a commit record in the redo log buffer and writes it to disk immediately, along with the commit SCN and transaction’s redo entries.
Note: LGWR can write redo log entries to disk before a transaction commits. The redo entries become permanent only if the transaction later commits.
When activity is high, LGWR can use group commits. For example, a user commits, causing LGWR to write the transaction’s redo entries to disk. During this write other users commit. LGWR cannot write to disk to commit these transactions until its previous write completes. Upon completion, LGWR can write the list of redo entries of waiting transactions (not yet committed) in one operation. In this way, the database minimizes disk I/O and maximizes performance. If commits requests continue at a high rate, then every write by LGWR can contain multiple commit records.
Checkpoint Process (CKPT):
1. Checkpoint process (CKPT) updates the control file and data file headers with checkpoint information and signals DBWn to write blocks to disk.
2. Checkpoint information includes the checkpoint position, SCN, location in online redo log to begin recovery
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.
Recoverer Process (RECO):
1. RECO is a background process for distributed transactions. The RECO process manager two-phase commits to track and resolve in-doubt transactions.
2. In a distributed database, the recoverer process (RECO) automatically resolves failures in distributed transactions.
The discussion does not end here. Keep on reading..
Hope it helps…