Brief Introduction to functions of Oracle background processes

Welcome to the Oracle community forum and interact with 2 million technical staff to enter the DBWR process. This process writes data files into the buffer zone and is an ORACLE background process responsible for Buffer Storage zone management. 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 make the Buffer Zone

Welcome to the Oracle community forum and interact with 2 million technical staff> Go To The DBWR process: This process writes data files into the buffer zone for execution. It is an ORACLE background process responsible for Buffer Storage zone management. 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 make the Buffer Zone

Welcome to the Oracle community forum and interact with 2 million technical staff> enter

DBWR process: This process writes a buffer into a data file. It is an ORACLE background process responsible for Buffer Storage zone management. 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:

When a server process moves a buffer into the dirty table, 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.

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. If a timeout occurs (3 seconds each time), DBWR notifies itself. When a checkpoint occurs, LGWR notifies DBWR. In the first two cases, DBWR dirty blocks in the table are written to the disk, with each writable block 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 instances, 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:

When a user process commits a transaction, a commit record is written.

Output the log buffer every three seconds.

When 1/3 of the log buffer is full, the log buffer is output.

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 the same as transaction log entry 1.

Logs are recorded in logs. As the SCN is recorded in the log, the restoration operation can be synchronized when the parallel server option is configured.

CKPT process: This process changes the title of all data files at the check point to indicate the checkpoint. Generally, this task is executed by LGWR. However, if the checkpoint significantly reduces system performance, the CKPT process can run to separate the work of the checkpoint originally executed by the LGWR process, which is implemented by the CKPT process. For many applications, the CKPT process is unnecessary. CKPT runs only when the database has many data files and the LGWR significantly reduces the performance at the check point. The CKPT process does not write blocks to the disk. This task is completed by DBWR.

The initialization parameter CHECKPOINT-PROCESS controls the enabling or enabling of CKPT processes. The default value is FALSE.

SMON process: when a process instance is started, it executes instance recovery and cleans 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.

PMON process: when a user process encounters a fault, the PMON process recovers and is 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 status of the scheduling process (DISPATCHER) and the server process. If it is dead, it restarts (excluding processes intentionally deleted ).

PMON is wake up regularly to check whether it is needed or other processes can be called when it is found necessary.

RECO process: This process is used when distributed options are available. It automatically resolves faults in distributed transactions. A node RECO background process automatically connects to other databases that contain pending distributed transactions, and RECO automatically resolves all pending transactions. Any row corresponding to the suspended transactions that have been processed is deleted from the suspended transaction table of each database.

When the RECO background process of a database server tries to establish communication with the same remote server, if the remote server is unavailable or the network connection cannot be established, the RECO will automatically connect again after a time interval.

The RECO background process only appears in the system that allows DISTRIBUTED transactions, and DISTRIBUTED? The c transactions parameter is greater than 0.

ARCH process: This process copies the filled online log files to the specified storage device. The ARCH process exists only when logs are used by ARCHIVELOG and can be archived automatically.

LCKn process: Used in an environment with parallel server options. Up to 10 processes (LCK0, LCK1 ......, LCK9), used for blocking between instances.

Dnnn PROCESS (scheduling PROCESS): This PROCESS allows user processes to share limited SERVER processes ). When no scheduling PROCESS exists, each user PROCESS requires a special service PROCESS (dedicatedserver process ). A multi-threaded SERVER (MULTI-THREADED SERVER) supports multiple user processes. If there are a large number of users in the system, the multi-clue server can support a large number of users, especially in the client _ server environment.

You can create multiple scheduling processes in a database instance. Create at least one scheduling process for each network protocol. The database administrator determines the optimal number of schedulers to be started based on the number of connections allowed by each process in the operating system. The scheduling process can be added or deleted when the instance is running. The multi-clue server requires SQL * NET version 2 or a later version. In the configuration of the Multi-clue server, a network receiver process waits for the client application connection request and sends each request to a scheduling process. If the customer application cannot be connected to one scheduling

The Network receiver process starts a dedicated server process. The Network receiver process is not a component of an ORACLE instance. It is a component of a network process related to ORACLE. When the instance is started, the network receiver is opened to establish a communication path for the user to connect to ORACLE. Then, each scheduling process gives the address of the scheduling process connecting the request to its receiver. When a user process is connected

When receiving a request, the network receiver process analyzes the request and determines whether the user can use a scheduling process. If yes, the network receiver process returns the address of the scheduling process, and then the user process is directly connected to the scheduling process. Some user processes cannot communicate with scheduling processes (if users of SQL * NET versions are used), network receiver processes cannot connect such users to a scheduling process. In this case, the network receiver establishes a dedicated server process and establishes a suitable connection.