Oracle Background Process

Background processes are part of the database instance and perform maintenance tasks required to operate the database and to maximize performance for multiple users.

Each background process performs a unique task but works with the other processes. Oracle Database creates background processes automatically when you start a database instance.

        When you start a database instance, mandatory background processes automatically start. You can start optional background processes later as required.

        Mandatory background processes are present in all typical database configurations. These processes run by default in a read/write database instance started with a minimally configured initialization parameter file. A read-only database instance disables some of these processes.

        Mandatory background processes include the Process Monitor Process (PMON), Process Manager Process (PMAN), Listener Registration Process (LREG), System Monitor Process (SMON), Database Writer Process (DBWn), Checkpoint Process (CKPT), Manageability Monitor Process (MMON), Manageability Monitor Lite Process (MMNL), Recoverer Process (RECO), and Log Writer Process (LGWR).

        Most optional background processes are specific to tasks or features. Some common optional processes include Archiver Processes (ARCn), Job Queue Coordinator Process (CJQ0), Recovery Writer Process (RVWR), Flashback Data Archive Process (FBDA), and Space Management Coordinator Process (SMCO).

        Slave processes are background processes that perform work on behalf of other processes; for example, the Dispatcher Process (Dnnn) and Shared Server Process (Snnn).

Mandatory Background Process

Process Monitor Process (PMON) Group

        The PMON group includes PMON, Cleanup Main Process (CLMN), and Cleanup Helper Processes (CLnn). These processes are responsible for the monitoring and cleanup of other processes.

        The PMON group oversees cleanup of the buffer cache and the release of resources used by a client process.

Process Monitor Process (PMON)

        The process monitor (PMON) detects the termination of other background processes. If a server or dispatcher process terminates abnormally, then the PMON group is responsible for performing process recovery. Process termination can have multiple causes, including operating system kill commands or ALTER SYSTEM KILL SESSION statements.

Cleanup Main Process (CLMN)

        PMON delegates cleanup work to the cleanup main process (CLMN). The task of detecting abnormal termination remains with PMON.

        CLMN periodically performs cleanup of terminated processes, terminated sessions, transactions, network connections, idle sessions, detached transactions, and detached network connections that have exceeded their idle timeout.

Cleanup Helper Processes (CLnn)

CLMN delegates cleanup work to the CLnn helper processes.

        The CLnn processes assist in the cleanup of terminated processes and sessions. The number of helper processes is proportional to the amount of cleanup work to be done and the current efficiency of cleanup.

        Oracle Database can use multiple helper processes in parallel to perform cleanup, thus alleviating slow performance.

Process Manager (PMAN)

        Process Manager (PMAN) oversees several background processes including shared servers, pooled servers, and job queue processes.

PMAN monitors, spawns, and stops the following types of processes:

• Dispatcher and shared server processes
• Connection broker and pooled server processes for database resident connection pools
• Job queue processes
• Restartable background processes

Listener Registration Process (LREG)

        The listener registration process (LREG) registers information about the database instance and dispatcher processes with the Oracle Net Listener.

        When an instance starts, LREG polls the listener to determine whether it is running. If the listener is running, then LREG passes it relevant parameters. If it is not running, then LREG periodically attempts to contact it.

In releases before Oracle Database 12c, PMON performed the listener registration.

System Monitor Process (SMON)

The system monitor process (SMON) is in charge of a variety of system-level cleanup duties.

Duties assigned to SMON include:

• Performing instance recovery, if necessary, at instance startup. In an Oracle RAC database, the SMON process of one database instance can perform instance recovery for a failed instance.
• Recovering terminated transactions that were skipped during instance recovery because of file-read or tablespace offline errors. SMON recovers the transactions when the tablespace or file is brought back online.
• Cleaning up unused temporary segments. For example, Oracle Database allocates extents when creating an index. If the operation fails, then SMON cleans up the temporary space.
• Coalescing contiguous free extents within dictionary-managed tablespaces.

SMON checks regularly to see whether it is needed. Other processes can call SMON if they detect a need for it.

Database Writer Process (DBW)

        The database writer process (DBW) writes the contents of database buffers to data files. DBW 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, DBWa through DBWz, and BW36 through BW99 to improve write performance if your system modifies data heavily. 

The DBW process writes dirty buffers to disk under the following conditions:

• When checkpoint occur- every 3sec
• When dirty buffer reached the threshold limit.
• When checkpoint timeout and no free buffer
• Table drop and truncate
• Tablespace begin backup
• Tablespace read only mode
• Tablespace in offline
• RAC ping request

        The DB_WRITER_PROCESSES initialization parameter specifies the number of Database Writer Processes. There can be 1 to 100 Database Writer Processes. The names of the first 36 Database Writer Processes are DBW0-DBW9 and DBWa-DBWz. The names of the 37th through 100th Database Writer Processes are BW36-BW99.

Log Writer Process (LGWR)

        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.

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 must write modified buffers to disk.

        Before DBW can write a dirty buffer, the database must write to disk the redo records associated with changes to the buffer (the write-ahead protocol). If DBW discovers 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.

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.

LGWR and Inaccessible Files

        If a log file is inaccessible, then LGWR continues writing to other files in the group and writes an error to the LGWR trace file and the alert log. If all files in a group are damaged, or if the group is unavailable because it has not been archived, then LGWR cannot continue to function.

Checkpoint Process (CKPT)

        The checkpoint process (CKPT) updates the control file and data file headers with checkpoint information and signals DBW to write blocks to disk. Checkpoint information includes the checkpoint position, SCN, and location in online redo log to begin recovery.

A checkpoint is a crucial mechanism in consistent database shutdowns, instance recovery, and Oracle Database operation generally.

Purpose of Checkpoints

• Reduce the time required for recovery in case of an instance or media failure.
• Ensure that the database regularly writes dirty buffers in the buffer cache to disk.
• Ensure that the database writes all committed data to disk during a consistent shutdown.

When Oracle Database Initiates Checkpoints?

        The checkpoint process (CKPT) is responsible for writing checkpoints to the data file headers and control file.

        Checkpoints occur in a variety of situations. For example, Oracle Database uses the following types of checkpoints:

Thread checkpoints

        The database writes to disk all buffers modified by redo in a specific thread before a certain target. Thread checkpoints occur in the following situations:

• Consistent database shutdown
• ALTER SYSTEM CHECKPOINT statement
• Online redo log switch
• ALTER DATABASE BEGIN BACKUP statement

Tablespace and data file checkpoints

A tablespace checkpoint is a set of data file checkpoints, one for each data file in the tablespace.

        These checkpoints occur in a variety of situations, including making a tablespace read-only or taking it offline normal, shrinking a data file, or executing ALTER TABLESPACE BEGIN BACKUP.

Incremental checkpoints

        An incremental checkpoint is a type of thread checkpoint. Partly intended to avoid writing large numbers of blocks at online redo log switches. DBW checks at least every three seconds to determine whether it has work to do. When DBW writes dirty buffers, it advances the checkpoint position, causing CKPT to write the checkpoint position to the control file, but not to the data file headers.

        Other types of checkpoints include instance and media recovery checkpoints and checkpoints when schema objects are dropped or truncated.

Manageability Monitor Processes (MMON and MMNL)

           MMON performs many tasks related to manageability, including taking Automatic Workload Repository snapshots and performing Automatic Database Diagnostic Monitor analysis.

        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)

In a distributed database, the recoverer 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.

Recovery Writer Process (RVWR)

 

When you use Flashback Database, the recovery writer process (RVWR) reads flashback data from the flashback buffer in the system global area (SGA) and writes to the flashback logs. That is, it undoes transactions from the current state of the database to a time in the past, provided that you have the required flashback logs.

Optional Background Processes

An optional background process is any background process not defined as mandatory.

Most optional background processes are specific to tasks or features. For example, background processes that support Oracle ASM are only available when this feature is enabled.

some common optional processes:

• Archiver Processes (ARCn)
• Job Queue Processes (CJQ0 and Jnnn)
• Flashback Data Archive Process (FBDA)
• Space Management Coordinator Process (SMCO)

Archiver Processes (ARCn)

An archiver process (ARCn) copies 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. ARCn processes exist only when the database is in ARCHIVELOG mode and automatic archiving is enabled.

Job Queue Processes (CJQ0 and Jnnn)

The job coordinator process (CJQ0) is automatically started and stopped as needed by Oracle Scheduler. The coordinator process dynamically spawns job queue slave processes (Jnnn) to run the jobs.

The initialization parameter JOB_QUEUE_PROCESSES represents the maximum number of job queue processes that can concurrently run on an instance. The coordinator process is not started if the initialization parameter JOB_QUEUE_PROCESSES is set to 0.

Flashback Data Archive Process (FBDA)

Flashback Data Archive Process is responsible for automatically managing the flashback data archive for space, organization (partitioning tablespaces), and retention. Additionally, the process keeps track of how long the archiving of tracked transactions has occurred.

Space Management Coordinator Process (SMCO)

The SMCO process coordinates the execution of various space management related tasks. Typical tasks include proactive space allocation and space reclamation. SMCO dynamically spawns slave processes (Wnnn) to implement the task.

Slave Processes

Slave processes are background processes that perform work on behalf of other processes.

 

Note:-

Background Process Reference

Database Limites