ORACLE process

ORACLE process
ORACLE The process during the interaction between client and server is divided into user process and ORACLE process. When a user runs an ORACLE client application, such as a PRO*C program or an ORACLE tool (such as SQL*PLUS), a user process is created for the application the user is running. ORACLE processes are divided into two categories: server processes and background processes. The server process is used to handle requests from user processes connected to the instance.
When the application and ORACLE are running on the same machine instead of through the network, the user process and its corresponding server process are generally combined into a single process to reduce system overhead. However, when the application and ORACLE run on different machines, the user process communicates with ORACLE through a separate server process. It can perform the following tasks:
(1) Syntax analysis and execution of SQL statements issued by the application
(2) Read the necessary data blocks from the disk data file to the SGA's shared database buffer (the block is not in the buffer) When)
(3) Return the result to the application for processing.
In order to achieve the best performance and coordinate multiple users, the system uses some additional processes in a multi-process system, called background processes. In many operating systems, background processes are created automatically when the instance starts.
An ORACLE instance has multiple background processes, namely: DBWR (database writing process), LGWR (log writing process), CKPT (checkpoint process), SMON (system monitoring process), PMON (process monitoring process), ARCH ( Archiving process), RECO (recovery process). Each background process interacts with a different part of the ORACLE database, the first 5 processes are required, and the last 2 processes are optional.
The following is a brief introduction to the functions of the background process.
1. DBWR process
The function of this process is to write the buffer to the data file. It is an ORACLE background process responsible for buffer storage management. When a buffer in the buffer is modified, it is marked as "dirty". The main task of DBWR is to write the "dirty" buffer to disk to keep the buffer "clean".
The number of unused buffers decreases as the cache's buffers fill up the database or become dirty by user processes. When the unused buffer area drops to such a small amount that the user process cannot find the unused buffer area when it wants to read blocks from the disk to the memory storage area, DBWR will manage the buffer storage area, and the user process can always get the unused buffer area by using
buffer zone.
ORACLE uses the LRU (LEAST RECENTLY USED) algorithm (least recently used algorithm) to keep the data blocks in memory recently used to minimize I/O. DBWR writes dirty buffers to disk under the following conditions.
(1) When a server process moves a buffer into a "dirty" table and the dirty table reaches a critical length, the service process will notify DBWR to write. The critical length is half the value of parameter DB-BLOCK-WRITE-BATCH.
(2) When a server process looks for the DB-BLOCK-MAX-SCAN-CNT buffer in the LRU table and no unused buffer is found, it stops looking and notifies DBWR to write.
(3) When a timeout occurs (3 seconds each time), DBWR will notify itself.
(4) When a checkpoint occurs, LGWR will notify DBWR.
In the first two cases, DBWR will write the blocks in the dirty table to disk. The number of blocks that can be written at a time is specified by the initialization parameter DB-BLOCK-WRITE-BATCH. If there is no buffer with the specified number of blocks in the dirty table, DBWR looks for another dirty buffer from the LUR table.
If DBWR is inactive for three seconds, a timeout occurs. In this case DBWR searches the LRU table for the specified number of buffers and writes any dirty buffers found to disk. If the database is idle, DBWR eventually writes the entire buffer store to disk.
When a checkpoint occurs, LGWR specifies that a modified buffer table must be written to disk. DBWR writes the specified buffer to disk.
On some platforms, one instance can have multiple DBWRs. In such an instance, some blocks may be written to one disk and other blocks may be written to other disks. The parameter DB-WRITERS controls the number of DBWR processes.
2. 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 prints all log entries since the last time it was written to disk. The LGWR process writes the log buffer contents to disk under the following conditions.
(1) Write a commit record when the user process commits a transaction.
(2) Output the log buffer every three seconds.
(3) Output the log buffer when 1/3 of the log buffer is full.
(4) When DBWR writes the modification buffer to disk, the log buffer is output.
The LGWR process writes to the active mirror online log file group synchronously. If a file in a group is deleted or becomes unavailable, LGWR can continue writing to other files in the group.
The log buffer is a circular buffer. After LGWR writes the log entries in the log buffer to the log file, the server process can write new log entries to the log buffer. LGWR typically writes very quickly, ensuring that there is always room in the log buffer for new log entries to be written. When a transaction commits,
is assigned a system modification number (SCN), which is recorded in the log along with the transaction log entry.
3. CKPT process
When the process is awakened for execution, the headers of all data files are modified, indicating the checkpoint, and notifying DBWR to write dirty data blocks to the data files.
4. SMON process
The role of this process is to perform instance recovery when the ORACLE instance is started, and is also responsible for cleaning up temporary segments that are no longer used.
5. PMON process
This process performs process recovery when the user process fails, and is responsible for cleaning up the private storage area and releasing the resources used by the process. For example, it resets the state of the active transaction table, releases the blockade, and removes the failed process ID from the active process table.
6． RECO process
This process is a process used when having the distributed option to automatically resolve failures in distributed transactions.
7． ARCH process
This process copies the filled online log files to the specified storage device. The ARCH process only exists when the log is used for ARCHIVELOG and can be archived automatically.

The above is the content of the ORACLE process. For more related articles, please pay attention to the PHP Chinese website (www.php.cn)!