CKPTQ: The data block in the Checkpoint Queue records the LRBA address of each data block.
Consists of three parts: 4 byte + 4 byte + 2 byte
Logfile sequence number (log file serial number)
Logfile block number (Log File block number)
Byte offset into the block (number of starting offset bytes of redo log records in the log block)
LRBA: Low cache RBA (the address corresponding to the redo log file when the dirty blocks in the buffer cache become dirty for the first time, that is, the location of the current checkpoint Queue)
HRBA: High cache RBA (the address corresponding to the redo log file when the dirty blocks in the buffer cache last become dirty)
On disk RBA: The last log address in the CURRENT status in the redo log file
In the database system, writing logs and writing data files are the two most IO-consuming operations in the database. In these two operations, writing data files is a distributed write, while writing log files is sequential write, therefore, to ensure the performance of the database, the database usually ensures that logs are written to the log file before the commit (commit) is completed, dirty data blocks are stored in the buffer cache and occasionally written into data files in batches. That is to say, the log writing and submission operations are synchronized, while the data writing and submission operations are not synchronized. In this way, there is a problem. When a database crashes, it cannot guarantee that all the dirty data in the cache is written into the data file, in this way, when the instance is started, the log file will be used to restore the database to the State before the crash to ensure data consistency. A checkpoint is an important mechanism in this process. It is used to determine which redo logs should be scanned during restoration and applied to restoration.
Generally, the checkpoint is a database event. The checkpoint event is issued by the checkpoint Process (LGWR/CKPT process). When the checkpoint event occurs, DBWn writes dirty blocks to the disk, at the same time, the data file and the control file header will be updated to record the checkpoint information.
Checkpoint:
This refers to writing dirty data to the hard disk to ensure that the memory and disk data are the same;
To recover an instance, you need to use logs to restore the dirty data that has not been written to the disk before the instance is shut down abnormally. If there are too many dirty blocks, the instance will be restored for a long time, the occurrence of checkpoints can reduce the number of dirty blocks and increase the instance recovery time.
If the initialization parameter LOG_CHECKPOINTS_TO_ALERT is set to TRUE, information about each checkpoint is recorded in the alert _ $ Oracle_SID.log file. The default value of this parameter is FALSE, indicating that no checkpoint is recorded.
In Oracle, checkpoints are divided into three types: Full checkpoints, incremental checkpoints, and partial (temporary) checkpoints.
Full checkpoint
Before Oracle8i, all database checkpoints are full checkpoints.
A full checkpoint will trigger DBWn to write all the dirty data blocks in the buffer cache to the corresponding data file (even if the transaction is not committed) and synchronize the information in the data file header and control file, ensure Database Consistency.
A full checkpoint occurs after 8 I only in the following two cases:
Database shutdown (immediate, transcational, normal)
DBA manual command intervention (alter system checkpoint)
Oracle architecture series related articles:
SCN and instance recovery in Oracle Architecture
Checkpoints of Oracle Architecture
Oracle architecture-SQL statement execution process
For more details, please continue to read the highlights on the next page: