Cooperation between OracleDBWnCKPTLGWR Processes

DBWn: Database block writer (DatabaseBlockWriter) is responsible for the background process of writing dirty blocks to the disk. CKPT: CheckpointProcess

DBWn: the Database Block Writer is responsible for the background process of writing dirty blocks to the disk. CKPT: Checkpoint Process

DBWn: the Database Block Writer is responsible for the background process of writing dirty blocks to the disk.

CKPT: The Checkpoint Process is only the header of the file for updating the data file to assist in creating the Checkpoint Process (DBWn ).

LGWR: Log Writer is responsible for refresh and output the content in the SGA to the disk.

In fact, these three processes are designed to better accomplish one thing: to securely and efficiently write data blocks in the memory into data files, that is, to reflect the modified data in the memory to the data files on the hard disk.

Writing memory data blocks to data files is a complicated process. In this process, you must first ensure security. The so-called security means that in the process of writing, once an instance crashes, a complete mechanism is required to ensure that the data submitted by the user will not be lost. Secondly, on the basis of ensuring security, improve efficiency as much as possible. As we all know, I/O operations are the most expensive, so we should try to collect dirty data blocks to a certain extent and then write them into the disk in batches.

The simplest solution is to hand over the changed memory data block to DBWn whenever the user submits it and write it into the data file. In this way, the submitted data will not be lost. However, this method is the most inefficient. In a high-concurrency environment, competition for I/O will surely occur. Oracle certainly won't adopt this non-scalability method. Oracle introduced the CKPT and LGWR background processes. These two processes work with the DBWn process to provide a safe and efficient solution for writing dirty data blocks.

How to ensure security?

Each time a user process modifies a memory data block, it constructs a redo entry in the log buffer ), this redo entry describes the values of the modified data block before and after modification. The LGWR process is responsible for writing these redo entries to the online log file. As long as the redo entries enter the online log file, the data security is guaranteed. Otherwise, the data is prone to security risks. LGWR is a process that must communicate with the foreground user process. LGWR undertakes the task of maintaining system data integrity, which ensures that data will not be lost under any circumstances.

What if DBWR suddenly crashes an instance while writing dirty data blocks? We already know that Oracle does not necessarily write the committed data blocks into the data files when users submit the data. When the instance crashes, some memory data blocks that have been submitted but not written to the data file will be lost. When the instance is started again, Oracle needs to reconstruct the lost data block in the buffer cache using the redo entries recorded in the log file to complete the rollback and rollback tasks, and retrieve the lost data blocks. So there is a problem here, that is, what redo entries should Oracle find when looking for redo entries in the log file? In other words, where should I start applying redo entries in the log file? Note that there may be more than one log file.

This starting point is of great significance. The dirty data blocks in the buffer cache corresponding to the redo entries located before this starting point have been written into the data file, therefore, you do not need to consider the restoration after the instance crashes. The dirty data blocks corresponding to the redo entries after this starting point are not actually written into the data file. If the instance is recovered after the crash, you need to start from this starting point, extract the redo entries in the log file in sequence for restoration. Considering that the current memory capacity is getting bigger and bigger, the buffer cache is also getting bigger and bigger. It is normal that the buffer cache contains millions of memory data blocks, how can we locate this starting point most effectively?

To determine the optimal starting point, Oracle introduced a background process named CKPT, which is usually called a checkpoint process ). This process works with DBWn to determine the starting point. At the same time, this starting point also has a special name, called the checkpoint position, which is recorded in the control file ). In order to make the checkpoint algorithm more scalable (that is, to be able to work effectively under a huge buffer cache), Oracle introduces the checkpoint queue (checkpoint queue ), the buffer header corresponding to the dirty data block is serialized on the queue. Each time DBWn writes dirty data blocks, it also scans dirty data blocks from the checkpoint queue and actually writes these dirty data blocks to the data files. After writing the data, DBWn removes the dirty data blocks that have been written to the data file from the checkpoint queue. In this way, even working in a huge buffer cache, CKPT can quickly determine which dirty data blocks have been written into the data file, and which have not yet been written into the data file. Obviously, as long as the data blocks in the checkpoint queue are dirty data blocks that have not been written into the data file. At the same time, in order to minimize the recovery time after the instance crashes, Oracle also introduced the incremental checkpoint (incremental checkpoint), which increased the number of checkpoint start times. If the interval between the start of each checkpoint is too long, and the memory is large, the recovery time may be too long. This is because the starting point is identified after the previous checkpoint is started. Before the second checkpoint is started, DBWn may have written many dirty data blocks to the data file. If the instance crashes before the second checkpoint is started, the identified start point is still identified when the last checkpoint was started. As a result, Oracle does not know that the dirty data blocks corresponding to many redo entries after this start point have actually been written into the data file, this results in Oracle repeat the process when the instance is restored, resulting in low efficiency and a waste of time.

Two important concepts about CKPT are mentioned above: Checkpoint Queue (including file Queue) and incremental checkpoint. The buffer headers in the checkpoint queue are arranged according to the sequence of the first time the data block is modified. The earlier the modification, the buffer header of the data block is placed in the front. If a data block is modified multiple times, it appears only once on the linked list. The buffer header in the checkpoint queue also records the address of the corresponding redo entry in the redo log file when the dirty data block is modified for the first time ,, that is, LRBA (Low Redo Block Address). Low indicates the RBA corresponding to the first modification. Each checkpoint is protected by the checkpoint queue latch.

The concept described above is summarized in one sentence. In fact, DBWn is responsible for writing dirty data blocks on the checkpoint queue, CKPT records the address of the redo entry corresponding to the first data block in the current checkpoint queue in the log file. The dirty data blocks to be written and the number of dirty data blocks to be written must be determined on the checkpoint queue.