Important background processes of oralce

When to trigger lgwr, dbwr, chpk, and other processes
Log writer (lgwr)
Lgwr performs sequential writes from the redo log buffer to the online redo log file under the followingsituations:
1. When a transaction commits
2. When the redo log buffer is

One-third full
3. When there is more than 1 MB of changes recorded in the redo log Buffer
4. Before dbwn writes modified blocks in the database buffer cache to
DataFiles
5. every three seconds

. Because the redo is needed for recovery, lgwr confirms the commit operation only after the redo is written todisk.
Lgwr can also call on dbwn to write to the data files.


Database writer (dbwn)
TheServerProcess records changes to undo and data blocks
In the database buffer cache. dbwn writes thedirty buffers from the database buffer cache to the data files. it ensures that a sufficient number of free buffers (buffers that can be overwritten when server processes need to read in blocks from the data files)
Are availablein the database buffer cache. database performance is improved because server processes make changes onlyin the database buffer cache.
Dbwn defers writing to the data files until one of the following events occurs:
Incremental or normal checkpoint
The number of dirty buffers reaches a threshold value
A process scans a specified number of blocks when scanning for free buffers and cannot find any
Timeout occurs
A Ping request in real Application Clusters (RAC) Environment
Placing a normal or temporary tablespace offline
Placing a tablespace in read-only mode
Dropping or truncating a table
Alter tablespacetablespace namebegin backup

1. When the dirty list length in the buffer cache reaches the threshold value:
Dbwr writes dirty buffer in the dirty list to the disk (when user server process searches for free buffer in the LRU list, it moves the dirty blocks encountered into the dirty list)

2. When the user server process searches for a long time in the LRU list of the buffer cache, it still does not find the free buffer:
Dbwr writes dirty buffer directly from the LRU list to the disk

3. Every 3 seconds:
Dbwr moves dirty buffers from the LRU list to the dirty list. Once the dirty list length reaches the threshold, dbwr writes data to the disk.

4. When a checkpoint occurs:
Dbwr moves all dirty buffers from the LRU list to the dirty list and writes data.

5. When tablespace starts Hot Backup:
Dbwr moves all dirty buffers belonging to the tablespace from the LRU list to the dirty list and starts to write data.

6. When tablespace is offline:
Dbwr moves all dirty buffers belonging to the tablespace from the LRU list to the dirty list and starts to write data.

7. When you execute drop:
DropTableOrIndexThis will prompt dbwr to first add the dirty that belongs to the segment.
Blocks write to disk


Checkpoint
Checkpoint isDatabaseEvent, which refreshes the modified data from the cache to the disk, and updates the control file and data file.
We know that the checkpoint will refresh the dirty data, but when will the checkpoint happen? In the following situations, checkpoint is triggered.

1. When a log group is switched
2. When the log_checkpoint_timeout, log_checkpoint_interval, fast_start_io_target, fast_start_mttr_target parameters are set
3. When you run alter system switch logfile
4. When you run alter system checkpoint
5. When you run alter tablespace XXX begin backup and end backup
6. When you run alter tablespace and datafile offline;
When to trigger lgwr, dbwr, chpk, and other processes
Log writer (lgwr)
Lgwr performs sequential writes from the redo log buffer to the online redo log file under the followingsituations:
1. When a transaction commits
2. When the redo log buffer is one-third full
3. When there is more than 1 MB of changes recorded in the redo log Buffer
4. Before dbwn writes modified blocks in the database buffer cache to the data files
5. every three seconds

. Because the redo is needed for recovery, lgwr confirms the commit operation only after the redo is written todisk.
Lgwr can also call on dbwn to write to the data files.

Database writer (dbwn)
The server process records changes to undo and data blocks in the database buffer cache. dbwn writes thedirty buffers from the database buffer cache to the data files. it ensures that a sufficient number of free buffers (buffers that can be overwritten
When server processes need to read in blocks from the data files) are availablein the database buffer cache. database performance is improved because server processes make changes onlyin the database buffer cache.
Dbwn defers writing to the data files until one of the following events occurs:
Incremental or normal checkpoint
The number of dirty buffers reaches a threshold value
A process scans a specified number of blocks when scanning for free buffers and cannot find any
Timeout occurs
A Ping request in real Application Clusters (RAC) Environment
Placing a normal or temporary tablespace offline
Placing a tablespace in read-only mode
Dropping or truncating a table
Alter tablespacetablespace namebegin backup
1. When the dirty list length in the buffer cache reaches the threshold value:
Dbwr writes dirty buffer in the dirty list to the disk (when user server process searches for free buffer in the LRU list, it moves the dirty blocks encountered into the dirty list)
2. When the user server process searches for a long time in the LRU list of the buffer cache, it still does not find the free buffer:
Dbwr writes dirty buffer directly from the LRU list to the disk
3. Every 3 seconds:
Dbwr moves dirty buffers from the LRU list to the dirty list. Once the dirty list length reaches the threshold, dbwr writes data to the disk.
4. When a checkpoint occurs:
Dbwr moves all dirty buffers from the LRU list to the dirty list and writes data.
5. When tablespace starts Hot Backup:
Dbwr moves all dirty buffers belonging to the tablespace from the LRU list to the dirty list and starts to write data.
6. When tablespace is offline:
Dbwr moves all dirty buffers belonging to the tablespace from the LRU list to the dirty list and starts to write data.
7. When you execute drop:
Drop table or index causes dbwr to write dirty blocks of the segment to the disk first.

A checkpoint is a database event that refreshes modified data from the cache to the disk and updates control files and data files.
We know that the checkpoint will refresh the dirty data, but when will the checkpoint happen? In the following situations, checkpoint is triggered.
1. When a log group is switched
2. When the log_checkpoint_timeout, log_checkpoint_interval, fast_start_io_target, fast_start_mttr_target parameters are set
3. When you run alter system switch logfile
4. When you run alter system checkpoint
5. When you run alter tablespace XXX begin backup and end backup
6. When you run alter tablespace and datafile offline;

Pmon process:
The process is executed when the user process fails.RestoreIs responsible for clearing the internal storage zone and releasing the resources used by the process. For example, it resets the status of the active transaction table, releases the block, and removes the ID of the faulty process from the active table. Pmon also periodically checks the scheduling process (dispatcher) andServerProcess status. If it is dead, restart (excluding processes that are intentionally deleted ).
Pmon is wake up regularly to check whether it is needed or other processes can be called when it is found necessary.

SMON process:
When the process instance is started, it executes instance recovery and is responsible for clearing temporary segments that are no longer in use. In an environment with the parallel server option, SMON recovers faulty CPU or instances. The SMON process is periodically woken up to check whether it is needed or whether it can be called when other processes discover it is needed.

Dbwr process:
This process writes the buffer to the data file and is responsible for caching the storage area.ManagementAn Oracle background process. When a buffer in the buffer zone is modified, it is marked as "dirty". The main task of dbwr is to write the "dirty" buffer to the disk to keep the buffer clean ". The number of unused buffers is reduced because the buffer zone is filled in the database or the user process is dirty. When unused buffers are dropped to a very small level, and user processes cannot find unused buffers when they want to read blocks from the disk to the memory storage area, dbwr manages the buffer areas, allows user processes to get unused buffers.
Oracle uses the LRU (least recently used) algorithm (the least recently used algorithm) to keep data blocks in memory recently used, minimizing I/O. In the following cases, dbwr needs to write dirty buffers to the disk:
1. When a server process moves a buffer into the "dirty" table and the dirty expression is critical, the service process will notify dbwr to write. The critical length is half the value of the parameter DB-BLOCK-WRITE-BATCH.
2. When a server process looks for the DB-BLOCK-MAX-SCAN-CNT buffer in the LRU table, there is no unused buffer, it stops searching and notifies dbwr to write.
3. If a timeout occurs (3 seconds each time), dbwr notifies itself.
4. When a checkpoint occurs, lgwr notifies dbwr that in the first two cases, dbwr dirty blocks in the table are written to the disk, and the number of writable blocks each time is specified by the initialization parameter DB-BLOCK-WRITE-BATCH. If the dirty table does not have a buffer with the specified number of blocks, dbwr looks for another dirty buffer from the Lur table. If dbwr is not active within three seconds, a timeout occurs. In this case, dbwr searches for a specified number of buffers for the LRU table and writes any dirty buffers to the disk. When timeout occurs, dbwr searches for a new buffer group. The number of buffers each time searched by dbwr is twice the value of the sleep parameter DB-BLOCK-WRITE-BATCH. If the database is transferred by air, dbwr eventually writes all the buffer zones to the disk.
When a Check Point occurs, lgwr specifies that a buffer table must be written to the disk. Dbwr writes the specified buffer to the disk. On Some platforms, one instance can have multiple dbwr instances. In such an instance, some blocks can be written to one disk, while others can be written to other disks. The number of dbwr processes is controlled by the parameter DB-WRITERS.

Lgwr process:
This process writes the log buffer to a log file on the disk. It is an oracle background process responsible for managing the log buffer. The lgwr process outputs all log entries since the last write to the disk, and the lgwr outputs:
1. When a user process commits a transaction, a commit record is written.
2. Log buffer output every three seconds.
3. When 1/3 of the log buffer is full, the log buffer is output.
4. When dbwr writes the modification buffer to the disk, It outputs the log buffer.
The lgwr process synchronously writes the image to the active online log file group. If a file in the group is deleted or unavailable, lgwr can continue to write other files in the group. The log buffer is a circular buffer. After lgwr writes log entries in the log buffer to the log file,
The server process can write new log entries to the log buffer. Lgwr is usually written very quickly to ensure that there is always space in the log buffer to write new log entries.
Note: Sometimes when more log buffers are required, lwgr writes log items before a transaction is committed, and these log items are only made permanent after the transaction is committed. Oracle uses the fast Submission mechanism. When a user issues a commit statement, a commit record is immediately placed in the log buffer, but the change in the corresponding data buffer is delayed, they are not written to data files until they are more effective. When a transaction is committed, it is assigned a system modification number (SCN), which is recorded together with the transaction log items in the log. As the SCN is recorded in the log, the restoration operation can be synchronized when the parallel server option is configured.