When an instance is started, Oracle Database allocates a memory area called the system global area (SGA) and starts one or more background processes.
Types of Processes:
Different types of database processes:
1: Client Process:
A client process can run on a host other than the database host. Client processes run the application or Oracle tool code.
2: Oracle processes:
Oracle processes run the Oracle database code. Oracle processes including the following subtypes:
2.1: Background processes:
Background processes start with the database instance and perform maintenance tasks such as performing instance recovery, cleaning up processes, writing redo buffers to disk, and so on.
2.2: Server processes:
Server processes perform work based on a client request.
For example, these processes parse SQL queries, place them in the shared pool, create and execute a query plan for each query, and read buffers from the database buffer cache or from disk.
Must Read: Recreate Temp Tablespace in Oracle
Mandatory Oracle Background Process
Process Monitor Process (PMON):
PMON monitors the other background processes and performs process recovery when a server or dispatcher process terminates abnormally.
You can check the status of PMON process using below command:
$ps -ef|grep pmon
PMON perform the below operations:
=> PMON is responsible for cleaning up the database buffer cache and freeing resources that the client process was using. For example, releases locks that are no longer required, and removes the process ID from the list of active processes.
=>PMON normally wakes up every 3 seconds to perform its housekeeping activities. PMON must always be running for an instance.
System Monitor Process (SMON):
SMON is in charge of a variety of system-level cleanup duties. You can check the status of SMON using below command:
$ps -ef|grep smon
SMON perform the below operations:
=> SMON wakes up every 5 minutes to perform housekeeping activities.
=> 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.
=> Performs critical tasks such as instance recovery or crash recovery when the instance is started following a failure.
=> 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 and maintenance tasks such as temporary space reclamation(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.), data dictionary cleanup, and undo tablespace management.
Database Writer Process (DBWn):
The database writer process (DBWn) writes modified blocks from the database buffer cache to the datafiles. The DBWn processes are responsible for writing modified (dirty) 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 DBWa through DBWj- to improve write performance if your system modifies data heavily.
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.
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 maximum number of DBWn processes is 20. If it is not specified by the user during startup, Oracle determines how to set DB_WRITER_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.
=> DBWn periodically writes buffers to advance the checkpoint, which is the position in the redo thread (log) from which instance recovery begins. This log position is determined by the oldest dirty buffer in the buffer cache.
Log Writer Process (LGWR):
The LGWR writes the redo log buffers to the on-line redo log files. If the on-line redo log files are mirrored, all the members of the group will be written out simultaneously (At the same time).
Oracle’s online redo log files record all changes made to the database. Oracle uses a “writeahead” protocol, meaning the logs are written to before the datafiles are.
If one of the files in the group is damaged or unavailable, LGWR continues writing to other files in the group and logs an error in the LGWR trace file and in the system alert log.
If all files in a group are damaged, or the group is unavailable because it has not been archived, LGWR cannot continue to function.
Log Writer Process writes redo records from Redo Log Buffer into redo log files since the last time it wrote under following circumstances:
=> 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.
=> DBWn must write modified buffers to disk.
Checkpoint Process (CKPT):
The checkpoint process (CKPT) updates the control file and data file headers with checkpoint information and signals DBWn to write blocks to disk. Checkpoint information includes the checkpoint position, SCN, location in online redo log to begin recovery, and so on.
Command to perform checkpoint:
Alter system checkpoint;
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.
Archiver Processes (ARCn):
The archiver processes (ARCn) 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. ARCn processes exist only when the database is in ARCHIVELOG mode and automatic archiving is enabled.
Alter system switch logfile;
Manageability Monitor Processes (MMON and MMNL):
MMON (Manageability Monitor) is a background process that gathers memory statistics (snapshots) and stores this information in the AWR (automatic workload repository). MMON is also responsible for issuing alerts for metrics that exceed their thresholds. 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.