Oracle Data Buffer Write principle

Because Oracle needs to prevent possible instance crashes at any time, Oracle will continue to locate this starting point during the normal operation of the database so that the data can be most effectively protected and recovered in an unexpected instance crash. At the same time, the choice of this starting point is very fastidious. First of all, this starting point cannot be too far ahead, too much of the previous meaning is to handle a lot of redo entries, which will cause the instance to recover too long when it is restarted, and second, the starting point cannot be too late, too late to say that only a few dirty blocks have not been written to the data file, In other words, there are already a lot of dirty data blocks are written to the data file, which means that only in the DBWR started very frequently, in order to make buffer cache the number of dirty blocks of data. However, it is obvious that the more frequently the DBWR is started, the more I/O of the Write data file is consumed, and the less I/O resources are left for other operations, such as reading blocks that do not exist in the buffer cache. This is clearly unreasonable.

As you can see from here, this starting point actually shows that the dirty blocks in the buffer cache that correspond to the redo entries in the log file before this starting point have been written to the data file, so that there is no need to consider the recovery after the instance crash. And after this beginning of the redo items corresponding to the dirty block is not actually written to the data file, if in the recovery after the instance crash, you need to start from this starting point, in turn, the log file in order to recover the redo entries. Considering the current memory capacity is more and more large, buffer cache is also more and more large, buffer cache contains millions of memory data block is also a normal phenomenon of the premise, how can the most effective to locate this starting point?

To best determine this starting point, Oracle introduced a background process called ckpt, often called a checkpoint process (checkpoint processes). This process works together with DBWR to determine this starting point. At the same time, this starting point also has a special name, called Checkpoint position (checkpoint position). Oracle, in order to be more scalable in the checkpoint algorithm (that is, to be able to work effectively under the huge buffer cache), introduces a checkpoint queue (checkpoint queue) that is strung with a buffer of dirty data blocks. Header And DBWR every time the dirty block is written, the dirty blocks are scanned from the checkpoint queue and the dirty blocks are actually written to the data file. When finished, DBWR the dirty block of data that has been written to the data file off the checkpoint queue. In this way, even under the huge buffer cache, CKPT can quickly determine which dirty blocks have been written to the data file, and which have not yet been written to the data file, apparently, as long as the data blocks on the checkpoint queue are dirty blocks of data that have not been written to the data file. Furthermore, Oracle specifically introduces file queues (Files queue) for more efficient processing of checkpoint space in Single-instance and multiple instance (RAC) environments, such as setting the tablespace to offline or hot backup state. The principle of file queues is the same as the checkpoint queue, it's just that each data file has a file queue, the data file's corresponding dirty blocks are strung on the same file queue, and in order to minimize the time of recovery after the instance crashes, Oracle also introduces an incremental checkpoint (incremental Checkpoint), which increases the number of checkpoints started. If the interval between checkpoints is too long, plus memory is large, it may take too long to recover. This starting point is identified since the previous checkpoint was started. And then, in the process of starting the second checkpoint, DBWR may have already written a lot of dirty chunks into the data file, and if an instance crash occurs before the second checkpoint starts, the identified starting point in the log file is still identified as the last checkpoint started, causing Oracle to not know this Many of the redo entries that come after the start are actually written to the data file, which makes Oracle repeat the process again when the instance is restored, inefficient and time-consuming.