Most relational databases have the advantage of performance by "not forcing modifications to the block at the time of submission" but rather "writing log files in the form of a record (in redo log)" when committing. That is, when a user commits a transaction, the write data file is "asynchronous" and the Write log file is "synchronous".
This can cause the database instance to crash when the modified data in the Db_buffer in memory may not be written to the data block. When the database is reopened, recovery is required to recover the state of the data in DB Buffer and to ensure that the data that has been committed is written to the data block.
Checkpoints are an important mechanism in this process to determine which redo logs should be scanned and applied to recovery when recovering.
After the checkpoint occurs, the CKPT process checks whether the checkpoint queue (that is, the dirty list) is too long and, if so, triggers the dbwn and writes a portion of the dirty block to the data file, shortening the checkpoint queue.
Checkpoint occurs, on the one hand notify DBWR to carry out the next batch of write operations, (DBWR write, once write the number of blocks is a bulk write hidden parameters control); On the other hand, Oracle uses a heartbeat concept to DBWR write progress to the control file at a frequency of 3 seconds, which is to write the SCN corresponding to the dirty buffer that DBWR is currently writing to the data file header and the control file, which is the checkpoint SCN.
This 3-second and incremental checkpoint is not a concept,3 seconds is just in the control file, the CKPT process to update the current DBWR write to where , this for ckpt process called Heartbeat, Heartbeat is 3 seconds once, 3 seconds can be regarded as a constant check and record Checkpoint Execution (DBWR write progress).
After the checkpoint occurs, the database data files, control files in a consistent state means that no media recovery is required, only the data file header is consistent, but does not mean that the data file content is consistent , Because the data file content may be in other cases where there is no checkpoint, the DBWR writes the data file, so that the data file content is inconsistent, if the power-down requires a crash recovery.
every 3 seconds ckpt will go to update the control files and data files, record checkpoint implementation of the situation.
The conditions that trigger the DBWR process are:
1. DBWR timeout, approx. 3 sec.
2. There is no extra empty buffer in the system to hold the data
3. CKPT Process Trigger DBWR
Checkpoint has two purposes:
1. Ensure consistency of data.
2, so that the database can be quickly restored.
The following process occurs during checkpoint:
1. DBWR Write all dirty data to the data file;
2. LGWR update the SCN for control files and data files.
This article from "Leboit" blog, declined reprint!
How checkpoint checkpoint Works