DBWR (Database Writer)

Database writer writes the content from buffer to datafiles .
The database writer process are responsible for writing modified (dirty buffers) in the database buffer cache to datafiles (disks).

The default is to have one database writer process, but large databases can have multiple DBWR processes.Before DBWn can write a modified buffer, all redo records associated with the 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 redo records to disk and waits for LGWR to complete writing the redo log buffer before it can write out the data buffers.
The purpose of DBWn is to improve system performance by caching writes of database blocks from the Database Buffer Cache back to datafiles. Blocks that have been modified and that need to be written back to disk are termed "dirty blocks."
The DBWn also ensures that there are enough free buffers in the Database Buffer Cache to service Server Processes that may be reading data from datafiles into the Database Buffer Cache.
Performance improves because by delaying writing changed database blocks back to disk, a Server Process may find the data that is needed to meet a User Process request already residing in memory!

How DBWn Works:

When a buffer in the database buffer cache is modified, it is marked dirty.A cold buffer is a buffer that has not been recently used according to the least recently used (LRU) algorithm. The DBWn process writes cold, dirty buffers to disk so that user processes are able to find cold, clean buffers that can be used to read new blocks into the cache. As buffers are dirtied by user processes, the number of free buffers diminishes. If the number of free buffers drops too low, user processes that must read blocks from disk into the cache are not able to find free buffers. DBWn manages the buffer cache so that user processes can always find free buffers.By writing cold, dirty buffers to disk, DBWn improves the performance of finding free buffers while keeping recently used buffers resident in memory.

For example,
blocks that are part of frequently accessed small tables or indexes are kept in the cache so that they do not need to be read in again from disk. The LRU algorithm keeps more frequently accessed blocks in the buffer cache so that when a buffer is written to disk, it is unlikely to contain data that will be useful soon.The initialization parameter DB_WRITER_PROCESSES specifies the number of DBWn processes. The maximum number of DBWn processes is depend upon oracle version . its vary from version to version . If it is not specified by the user during startup, Oracle determines how to set DB_BLOCK_PROCESSES based on the number of CPUs and processor groups.
The DBWn 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, it signals DBWn to write. DBWn writes dirty buffers to disk asynchronously while performing other processing.

PMON (Process Monitor)

The Process Monitor (PMON) monitors other background processes
It is a cleanup type of process that cleans up after failed processes.
Examples include the dropping of a user connection due to a network failure or the abnormal termination (ABEND) of a user application program.
It cleans up the database buffer cache and releases resources that were used by a failed user process.
PMON constantly checks the status of user and database processes. In some cases, failed database processes can be restarted by PMON.
PMON resets the status of the active transaction table, releases locks that are no longer required, and removes the process ID from the list of active processes.
PMON also registers information about the instance and dispatcher processes with the network listener (see "The Oracle Net Listener"). 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.

Like SMON, PMON checks regularly to see whether it is needed; it can be called if another
process detects the need for it.

SMON (System Monitor)

The System Monitor process (SMON) performs recovery at instance startup if necessary. SMON
is also responsible for cleaning up temporary segments that are no longer in use. If any
terminated transactions were skipped during instance recovery because of file-read or offline
errors, SMON recovers them when the tablespace or file is brought back online.
SMON checks regularly to see whether the process is needed. Other processes can call SMON if
they detect a need for it.
 Instance recovery consists of the following steps:

1. Rolling forward to recover data that has not been recorded in the data files but that has been recorded in the online redo log. This data has not been written to disk because of the loss of the SGA during instance failure. During this process, SMON reads the redo log files and applies the changes recorded in the redo log to the data blocks. Because all committed transactions have been written to the redo logs, this process completely recovers these transactions. its also perform crash recovery
2. Opening the database so that users can log on. Any data that is not locked by un recovered transactions is immediately available.
3. Rolling back uncommitted transactions. They are rolled back by SMON or by the individual server processes as they access locked data.

SMON also performs some space maintenance functions:

• It combines, or coalesces, adjacent areas of free space in the data files.
• It deallocates temporary segments to return them as free space in data files. Temporary segments are used to store data during SQL statement processing.
• In  RAC environment the SMON process of one instance can perform instance recovery for other instances that have failed.
• SMON wakes up about every 5 minutes to perform housekeeping activities

Oracle Background Process

To maximize the performance and accommodate many users, a multiprocessing oracle system use some additional database process called background process.
The relationship between the physical and memory structures is maintained and enforced by Oracle’s background processes.

Mandatory background process :

• System monitor (SMON)
• Process monitor (PMON)
• Database writer (DBWR)
• Log writer (LGWR)
• Checkpoint (CKPT)

Optional process:

• Archival  (ARCn)