Oracle Background Process Introduction

A Process classification:
1. Server process: Completes the work according to the customer request. such as receiving and processing the SQL statements sent by the application
2. Background processes (background process): Starts with the database and is used to complete various maintenance tasks. If you write blocks to disk (DBWN),
Maintenance of online redo logs (LGWR), cleanup of abnormally terminated processes, etc.
3. Dependent processes (slave process): Similar to background processes, but they do some extra work on behalf of a background process or server process.

Two main talk about the background process:

To explore the main process:

Sql> Select PADDR, Name, Description  2 from   v$bgprocess  3  where paddr <> ' xx '  4  Order by paddr desc  5  /

paddr                          name                     DESCRIPTION
----------------------------------------- --------------------------------------------
0000000084c92190  cjq0  Job Queue Coordinator
0000000084c8d050 smco  Space Manager Process
0000000084c8c010 qmnc  AQ Coordinator
0000000084C87F10 mmnl  Manageability Monitor Process 2
0000000084c86ed0 mmon  manageability Monitor Process
0000000084C85E90 reco  Distributed Recovery
0000000084c84e50 smon  System Monitor Process
0000000084c83e10 ckpt  checkpoint
0000000084c82dd0 lgwr  Redo etc.
0000000084c81d90 dbw0  DB Writer Process 0
0000000084c80d50 mman  Memory Manager

Paddr NAME DESCRIPTION
---------------- ----- ----------------------------------------------------------------
0000000084C7FD10 DIA0 diagnosibility Process 0
0000000084C7ECD0 PSP0 Process Spawner 0
0000000084C7DC90 DBRM DataBase Resource Manager
0000000084C7CC50 DIAG diagnosibility Process
0000000084C7BC10 GEN0 Generic0
0000000084c7abd0 Vktm Virtual Keeper of time process
0000000084C79B90 Pmon Process Cleanup

1. DBWR Process

The process executes an Oracle background process that writes buffers to the data file and is responsible for buffer store management. When a buffer in the buffer is modified, it is flagged as "dirty", and the main task of DBWR is to write the "dirty" buffer to the disk, leaving the buffer "clean". The number of unused buffers is reduced because buffers in the buffer store are populated into the database or are dirty by user processes. When the unused buffer drops to a minimum, and the user process is unable to find the unused buffer when it reads the block from the disk into the memory store, DBWR manages the buffer store so that the user process can always get an unused buffer.

Oracle uses the LRU (LEAST recently used) algorithm (the least recently used algorithm) to keep the in-memory data blocks most recently used, minimizing the I/O.

The conditions that trigger the DBWR process are:
1). DBWR timeout, approx. 3 sec.
2). There is no extra empty buffer in the system to hold the data
3). CKPT Process Trigger DBWR
On some platforms, an instance can have multiple DBWR. In such instances, some blocks can be written to one disk, and others can be written to other disks.

2. LGWR Process

The process writes the log buffer to a log file on disk, which is an Oracle background process responsible for managing the log buffers.

The conditions that trigger the LGWR process are:
1). User Submissions
2). There are 1/3 redo log buffers not written to disk
3). Redo log buffers with greater than 1M are not written to disk
4). 3 Seconds Timeout
5). DBWR the SCN that needs to write data is larger than the LGWR record SCN,DBWR trigger LGWR write.

The log buffer is a circular buffer. When LGWR writes a log entry for a log buffer to a log file, the server process can write a new log entry to the log buffer. LGWR is usually written very quickly, ensuring that the log buffers always have room to write new log entries.

Note: Sometimes when more log buffers are needed, LWGR writes out log entries before a transaction commits, and these log entries are only persisted after a subsequent transaction is committed.

Oracle uses the fast commit mechanism, when a commit statement is issued by a user, a commit record is immediately placed into the log buffer, but the corresponding data buffer changes are delayed until they are written to the data file when they are more efficient. When a transaction commits, it is assigned to a system modification number (SCN), which is recorded in the log along with the transaction log entry. Because the SCN is logged in the log, the recovery operation can be synchronized in the case of a parallel server Option configuration.

3. Pmon Process Monitoring Process
Pmon is responsible for monitoring the processing of the database and for cleaning up the dead process. Pmon is also responsible for restarting the failed dispatch in
Process (Dispatcher process)

4. Smon Process

Smon is a critical background process for an Oracle database that performs instance recovery at startup and cleans up temporary segments that are no longer in use, and is a "garbage collector" for libraries. In an environment with parallel server options, Smon restores instances of failed CPUs or instances. The Smon process is woken up regularly, checked for need, or can be called when other processes are found to be needed.

The work it does includes the following 7 pieces:

(1) Cleanup of temporary tablespace: With the advent of this "real" temporal tablespace, the chore of cleaning up the temporary table space has eased, but it has not completely disappeared. For example, when an index is established, the extents assigned to the index during creation are marked as temporary. If the CREATE index session is abnormally interrupted for some reason, Smon is responsible for cleaning them. Smon is also responsible for temporary extents created by other operations.
(2) Joining free space: If you are using a data dictionary to manage table spaces, Smon is responsible for combining the extent that are idle in the table space and are adjacent to each other for a larger free expansion area. This occurs only in a dictionary with a default pctincrease set to a non-zero storage clause to manage tablespace.
(3) Restore a transaction to an active state for a file that is not available: its role is similar to that during library startup. At this point, because the file cannot be used for recovery, Smon recovers a failed transaction that was skipped during instance/crash recovery. For example, the file may already be on a disk that is unavailable or not mounted. When the file becomes available, Smon will restore it.
(4) Perform an instance recovery of a failed node in a RAC: in an Oracle RAC configuration, when one of the library instances in the cluster fails (for example, a machine failure is being performed by the instance), some other nodes in the cluster will turn on the Redo log file for the failed instance and perform all data recovery for the failed instance.
(5) Cleanup obj$:obj$ is a row-level data dictionary table that contains records for almost every object in the library (tables, indexes, triggers, views, and so on). Many times, the records here represent deleted objects, or objects that are not here, are used in Oracle's trust mechanism. Smon is the process of removing these rows that are not required.
(6) Shrink rollback segment: Smon will perform a rollback segment that automatically shrinks to its optimal size if it is set.
(7) "Offline" rollback segment: It is possible for a DBA to have a rollback segment with active transactions offline or unavailable. It is possible for an active transaction to use this offline rollback segment. In this case, rollback is not really offline; it is flagged as "hanging offline". In the background process, Smon will periodically try to make it truly offline until it succeeds.

Smon does many other things, such as the scrubbing of monitoring statistics in the dba_tab_monitoring view, the SCN scrubbing of the timestamp location information found in the Smon_scn_time table, and so on. Smon can consume a lot of CPU during the period, which should be considered normal. The Smon periodically wakes up (or is woken up by other background processes) to perform the butler's household chores.

5.CKPT Checkpoint Process
The CKPT process is responsible for sending signals to the DBWR process, requiring a checkpoint and updating all data and control files for the database.
CheckPoint (checkpoint) refers to a DBWR process that writes all the modified data buffers back to the data file. CKPT is optional, if there is no ckpt process, there is a LGWR generation
These tasks.

6. ARCHN Archive Process
ARCH (The archiver Process) is responsible for copying the replay redo log to the archive memory. The input RDBMS runs in Archivelog mode, and arch is effective if
System is not running in Archivelog mode, the system may fail to recover after it has failed. Finally, let the system run in Archivelog mode, at which time there may be more than one archive process.
Sql>archive Log list//To see if it is in archive mode
Archive can be opened in the database Mount mode
Sql>alter database Archivelog; Open
Sql>alter database noarchivelog;//off

7. RECO Recovery Process
RECO (the Recovery process) processes are used to purge pending (pending) transactions in the distributed database, which is responsible for the commit and rollback of the local part of the distributed transaction

------------------------------

by Dylan.