Functional Differences Between checkpointqueue and lruw linked lists

Why Does Oracle have two dirty lists: One CheckpointQueue and one Lruw? The above descriptions are simplified. You may say that my descriptions are incorrect. Example: Oracle from Lr

Why Does Oracle have two dirty lists: one Checkpoint Queue and one Lruw? The above descriptions are simplified. You may say that my descriptions are incorrect. Example: Oracle from Lr

There was a long question:

Why should Oracle create two dirty lists: one Checkpoint Queue and the other Lruw?

Now you can give a periodic answer:

The purpose of the two linked lists is different. The Checkpoint Queue is sorted by the time the data block is modified for the first time (as long as the data block is dirty, it must be on this linked list ), dbwr writes dirty data along the Checkpoint Queue. The earlier the block that Oracle wants to modify, the earlier it will be written. This helps reduce the recovery time. But one thing is very important. After these blocks are written to a disk, 1) it will not change the position of the block in the Lru linked list. 2) this block is still in the memory (many people misunderstand that the block will not be in the memory after it is written dirty quickly ). The Lruw linked list is not for this purpose. It is designed to free up some space, so that the block that will be physically read later or the block that needs to be constructed CR can have a place in the Buffer Cache, in order to free up space, we need to sacrifice some blocks to free up space. Generally, Tch is smaller than 2, CR blocks, and full table scan blocks are sacrificed for reuse. When the system urgently needs a large number of idle blocks, if the process searches for the LRU linked list (including Lru-Aux), if dirty data is found quickly (because it is scanned from the Lru cold end, so the dirty Tch is also very small) So it will be moved to the Lruw linked list, and then written from the Lruw to the disk, and the Free memory block will be moved to the Lru-Aux for reuse, of course, this block needs to be removed from the Checkpoint Queue after it is written to the disk. After a block is changed to dirty, it will definitely enter the Checkpoint Queue, but will not immediately enter the Lruw Queue. If the number of Tch is small only when the process searches for the LRU linked list, will be put into the Lruw linked list and then written to the disk. As many people think, the Lru linked list should be a clean block. In fact, there should be a lot of dirty data in the Lru linked list, especially if your dirty data blocks are frequently accessed and the Tch count is relatively high, it is difficult to be flushed into the Lruw linked list, it will remain in the Lru connection table. Of course, this dirty block will eventually be written into a clean block from the Checkpoint Queue, but its position in the Lru linked list remains unchanged and will not be flushed out of the Buffer Cache.

The above descriptions are simplified. You may say that my descriptions are incorrect. For example, Oracle writes dirty data from Lruw quickly. The detailed process should be: first scan the Lruw linked list, and then move the data block without a pin to Lruw-Aux, then write the block in exclusive mode to the disk. We only need to explain the differences between the Checkpoint Queue and the Lruw linked list in the design purpose.